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

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

At 07:33 AM 1/29/2006, Hallvard B Furuseth wrote:
>> 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).
>
>Here I disagree.
>
>One purpose of this class is to satisfy a requirement of the X.500/LDAP
>model, that entries need a structural class, even when there is no
>interesting type to assign the object.

That purpose is met by the above.  The object has the structural
class untyped.

>The purpose of a class with naming attributes will also be to satisfy
>requirements of the model, that the RDN must have an attribute and the
>entry must have an object class which allows that attribute.

Yes, but nothing in the model as that the attribute must
be allowed directly by the structural object class of the
attribute type.

>(Unless a DIT content rule is used.)

Well, since you assuming use of auxiliary classes to allow
other attributes, you are (in the X.500 model) assuming use
of a DIT content rule.  

>In this sense, the structural class and the class which allows the
>naming attribute really has the same function - just to satisfy the
>model's reqirement. 

Again, the X.500 model doesn't require the structural
class to directly allow the naming attribute.  The
model allows these to be allowed through use of a
DIT Content Rule (allowing the particular attribute,
or allowing an auxiliary class that allows the attribute).

>The person who inserts the attribute and the
>class(es) does not intend to convey anything interesting in doing so.
>At least with attribute "cn" or a backwards-compatibility "ou", I don't
>know about other cases.  Why add two uninteresting classes to the entry
>instead of one?

My understanding of your intent is to use one structural
and some non-zero number of auxiliaries.

If you want to make it usable without a DIT content rule
(hence no additional attributes, no auxiliaries allowed),
then yes you would need at least one attribute type.

As I noted before, I could see allowing 'cn'... but I see
no reason to add 'all common naming attributes'.

>That said, I don't feel all that strongly about it.

Well, as I don't intend to use this class, I certainly don't
feel strongly about this either.  You could say I am just
playing the devil's advocate.

>> 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.
>
>Well, I disagree there too, but could go either way.  Except I'm still
>wondering about one detail, see below:-)
>
>(..snipping, would just repeat stuff..)
>
>>> 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?
>
>Why a bunch of classes that just allow one attribute, instead of one
>that allows several - even for auxiliary classes?
>Same with your describedObject, relatedObject, ownedObject.

Because each of these auxiliaries defines a distinct interface.

Of course, if you just want to allow everything, you only need
one class, it's called extensibleObject.

>In particular for this purpose - an ouObject class in the entry would
>actually look to someone reading the directory like intended to be
>informative - that the entry is some kind of organizational unit. A
>more general class, auxiliary or structural, would not imply that.
>
>>>>> 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.
>
>Metoo, though not more than the other names.
>
>I kind of like namedObject, actually.

If you define namedObject consistent with its current use in the
wild, no problem...



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