Re: [ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:

> I don't see way this class would have any MUST/MAY attributes
> (other than 'objectClass' as required by the SUP top).

Well, the rationale is in Appendix A, except:

> It seems that it would be more appropriate to use DIT content
> rules/auxiliary object classes (including possibly extensibleObject)
> to require/allow any desired attributes, including those used for
> naming.

I don't get this.  Plenty of other object classes can be used for a
number of different scenarios and provide a bunch of attributes that
just might be useful, e.g. the MAY attributes to 'person'.  That's
partly what MAY is for in the first place.  How is this different?
The major thing wrong I can see with this class is that it must be
structural but doesn't really deserve to be, not which attributes it
has.

And quite possibly it has too many naming attributes.  I can see
moving the other naming attrs than CN to an aux class which would
also be defined in the draft.

extensibleObject and DIT content rules may both be unsupported.
But it might be an idea to suggest them in the draft, in particular
if most/all attributes are deleted.

> I don't like the name of this class, but the alternatives don't seem
> much better (if better at all), 'unclassifiedObject',
> 'structurallessObject', 'unstructuredObject' (at present, I prefer the
> latter).

Yeah, they are all equally bad:-(  I could go for either.

structurallessObject... hmm, it sounded absolutely wrong at first
glance, but maybe not...

Or namedObject, which this version of the draft steals some text from.
Don't know where the namedObject draft is going or if this would be OK
with the author of that one.

> A few misc. comments (mostly editorial, but some of
> substance).

Leaving most for Alexey.

>   "This document raises no known security issues."
>   Well, given RFC 2256 discussions security considerations
>   for attributes such as CN, I would think there are
>   known security issues impacting this specification.
>   (...) I suggest
>   the authors read Section 7 of draft-zeilenga-ldap-ext
>   and attempt to satisfy its requirements/recommendations
>   here.

Good tip.

BTW, sorry about dropping this draft some time ago.  Alexey picked it up
again.

-- 
Hallvard

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext