Re: LDAP Subentry and naming

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

At 12:46 AM 3/30/00 -0700, Ed Reed wrote:
>During the LDUP discussion of the LDAP Subentry draft <http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-02.txt>
>the matter of naming attributes came up again, and we need to settle what the draft needs to say.
>
>Mark Wahl notes that some vendors have objected that CN is a poor choice for naming ldapSubEntry entries in the directory.  Since they'll not be visible to users and administrators, unless specifically requested, they'll be in a position to cause mysterious naming clashes with other entries named by CN.  The example being that if an ldapSubEntry exists with the name CN=fred, and an administrator attempts to create a person with CN=fred, the administrator will likely get a "duplicate entry name" like error (there's already an entry with the name CN=fred), but the administrator won't see the subentry.
>
>Since many ldapSubEntry entries will be created automatically by software in the operation of the directory, it's reasonable to name them something that won't cause such mysterious seeming errors as the one described above.
>
>There might be several possible solutions:
>
>1) define a new attribute, say ldapSE, of type DirectoryString, with which ldapSubEntry entries may be named.

I rather not introduce a new attribute solely to name subentries.

>2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information - this seems troublesome, as the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule is likely to be required, which could get in the way of subsequent users;

An alternative would be to define ldapSubEntry as ABSTRACT and leaving
naming to definers of structural subclasses.

	( X NAME 'ldapSubEntry' ABSTRACT DESC 'subentry abstract class' )

Of course, this leaves the name conflict issues with the structural
subclasses...

>3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators.


>Option 1 takes ldapSubEntry further and further away from the X.500 definition.  That's not a problem to the author, if that's desireable because we've learned a change to the X.500 model is warranted.
>
>Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY class itself, instead of a STRUCTURAL class, but I confess I don't understand the nuances being navigated by the X.500 vendors in the room.  At any event, this would be an even more serious diversion from the original X.500 model Subentry class definition, wouldn't it? - is that a problem?

I think AUXILIARY is a bad choice as a subentry is a subentry and an entry
is an entry and this must be establish when the entry is instantiated.
Use of AUXILIARY would allow for an entry to be changed into a subentry
and vice versa.

My suggestion:

Define LDAPsubentry as STRUCTURAL with MUST 'cn' but state that
naming with attributes other than CN is allowed.