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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:45 PM 1/22/2006, Alexey Melnikov wrote:
>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:

Yes, I just don't agree with the rationale.  I would rather
the class be defined not to allow any attribute that if
present, irregardless of value, be indicative of a particular
type of object.  That is, the allowed attributes should not
'type' the untyped object.  For instance, the presence of
'dc' implies the object can be typed as being domain related.

You note this in the I-D:
   Use of the [other attributes] may be an indication that the
   entry should have a more descriptive object class
   instead of or in addition to this one.

But I note that as attributes used for naming are also
descriptive of the object, your note should not only
apply to "[other attributes]", but to all attributes
of the class.

Even presence of cn can be viewed as typing the object as
being 'named'.  Instead of dividing the class by presence
of cn, I rather do this by class, either have namedObject
& unnamedObject structural classes, or untypedObject structrual
class and a cnObject auxiliary class.  And given that same
applies many of the other attributes (e.g., (dc=*) => object is
domain related)), the latter is the better choice.

That is, I think it would be better to have
        ( 1.1.1 NAME 'untyped' )
and a set of appropriate AUXILIARY classes for naming
and other uses (such as allowing/requiring attributes which
divide the class).

I'm not even convinced that description, seeAlso, and owner
don't divide the class and might be better brought in by
auxiliary classes, describedObject, relatedObject, ownedObject.

It seems this is more consistent with (my perception of) the
use model for the untypedObject class.  The use model seems
that objects of this class should belong to some number of
auxiliary classes.  This number should be non-zero.



>>>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.

I think its a bad idea to include attributes because
they might be used in naming some objects of the class.
I think its far better to use an auxiliary class or DIT
content rule to allow a naming attribute other than those
attributes used to represent the object.  For instance,
use of dcObject to allow 'dc'.

>>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.

Though I think it would be better to allow no attributes,
I could see an (untyped) object having a (common) name, uuid,
and description.  I could even see owner and seeAlso being
generic enough for to all for a class suitable for holding
any object.

But userid?  If the object has a user id, I would think the object
represents an user entity of some sort.  Adding 'uid' suggests a type of
object, and hence, I think inappropriate for 'untyped' objects.
Likewise for 'dc', 'l', 'o', etc..

>For the purposes I use this Object Class in Isode software I need cn, uid and dc.

What need can you not fulfill by using:
        untypedObject+cnObject
        untypedObject+uidObject
        untypedObject+dcObject
        untypedObject+extensibleObject
        untypedObject+...
        untypedObject+ DIT content rule

where untypedObject has no allowed attributes?

>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.

Yes, but there always regular auxiliary classes to allow in
desired attributes.  You can argue, I guess, that there might
be implementations that don't support auxiliary object classes.
There might even be such implementations (as LDAP doesn't
require implementation of the X.500 schema model).  But
such implementations should be ignored as you are defining
an X.500 schema element (for use in LDAP).

>>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.

I dislike the name Container as that implies it represents
objects that contain other objects.

>>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


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