RE: LDAP Subentry and naming

[Steven Legg <steven.legg@adacel.com.au>]

Ed,

There's a fourth option which is to keep CN as the naming attribute but
recommend a convention for naming subentries that makes a name clash
very unlikely. The convention could be as simple as "the CN of subentries
should begin with the text `subentry:' ".

I've been habitually using CN=Subschema for the subschema subentry for
years and it hasn't been a problem yet so I'm wondering how real a problem
this is. Mysterious name clashes are nothing new either since a user could
easily (and perhaps more likely) enter a name that clashes with an existing
entry that is invisible due to access controls.

Any software automatically generating subentries ought to have a backoff
strategy trying alternative names until one works, whatever the naming
attribute is, so I don't see a problem there.

I don't like the idea of leaving the choice of naming attribute to the
developers for such an important component of directory operation.
All the necessary definitions for LDUP subentries should be widely
known.

Regards,
Steven

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org
[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Ed Reed
Sent: Thursday, 30 March 2000 17:46
To: ietf-ldup@imc.org; ietf-ldapext@netscape.com
Subject: LDAP Subentry and naming


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

Option 3, it seems to me, should be our fall back if concensus can't be
reached quickly - by the end of April, for instance.  LDUP doesn't
particularly care.  That would mean leaving it as it is (I think).

Please reply by 23 April with your feelings, if you care.  If not, stay
tuned to see what develops.  I plan to submit this for last call by the end
of April, 2000.

Regards,
Ed Reed