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

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

OK, I finally got to this...

Kurt D. Zeilenga writes:
>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.

I've finally realized I left unsaid part of my own reason for including
other naming attributes than "cn":

1) "ou=people", "ou=users" etc is almost a de-facto standard for
   "container" entries, so I wanted to support it.  Just replacing the
   object class so a filter (objectClass=organizationalUnit) will not
   return ou=people, is likely a fairly small fix compared to renaming
   the tree to cn=people and fixing the base DN in a bunch of clients.
   The latter might not get done as quickly in an existing installation,
   if ever.

   Also, I have seen clients that "knew" what naming structure was used
   in the directory even if they didn't know the actual attribute values
   - like "ou" for container objects, and "o" for the top object.  So if
   such a client happens to be the motivation for setting up a quick
   LDAP installation...  That's a while back now though, we have mostly
   played with our own clients lately:-)

2) Since I included ou, it seemed reasonable to be a little consistent
   about it, and include other "official" naming attributes as well.

While I don't know what Alexey's reasons for wanting dc and uid, I
prefer to have at least "cn" and "description".  Still, auxiliary
classes would work fine for me as well - as long as we define and
publish them.  The reason ou did become widely used is probably just
that there wasn't a more suitable standard class.

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

Well, the attribute used for naming might just be descriptive in the
sense "we once used organizationalUnit for this object, lacking a better
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).

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.

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.
(Unless a DIT content rule is used.)

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

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

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

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.
Or uninterestingObject:-)

-- 
Hallvard

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