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

[Alexey Melnikov <alexey.melnikov@isode.com>]

Hallvard B Furuseth wrote:

> 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.
>  
For the purposes I use this Object Class in Isode software I need cn, 
uid and dc.
The description attribute seems to be a good idea for describing why an 
entry of this class is present in DIT.
I don't have strong opinion about other attributes.

> extensibleObject and DIT content rules may both be unsupported.
>  
Right.

> 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...
>  
I like the name Container, which is used by Microsoft AD for similar 
purposes.

> 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.
>  
I think Luke Howard has agreed to my idea of having a single merged draft.

> > A few misc. comments (mostly editorial, but some of
> > substance).
> >    
>
> Leaving most for Alexey.
>  
Yes, comments look straightforward.

> >  "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.
>  
Ok, I will think about Security Considerations for the next revision.

Alexey


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