Subject: Follow-up on Naming of Subentries

From: "Slone, Skip" <[email-masked]>
Date: Tue, 11 Dec 2001 16:55:08 -0500

Greetings to all,
 
Although I'm not able to make the SLC meeting this week, I do have some
comments to report back as a follow-up to the discussion we had in London.
At the close of the meeting, there were two subentry naming issues
outstanding that I was to take to the next X.500 meeting -- subordination of
subentries and use of subentry naming attributes other than cn.  
 
We discussed these topics at the X.500 meeting last month.  The consensus of
the group was that although we're not necessarily opposed to either of these
changes, we need to better understand the requirements, and we want to make
sure that by making the changes, we're not creating unintended additional
semantics. 
 
Bottom line -- we're open to making these changes as long as we understand
the requirements and we can make them in a way that avoids negative side
effects.  Our next meeting is in late February / early March (prior to IETF
53), so if we can get an articulation of the requirements before then, we
should be able to have a clear direction by the Minneapolis meeting.
 
Regards,
 
 -- Skip Slone

---

From: Mark Wahl <[email-masked]>
Date: Tue, 11 Dec 2001 16:44:23 -0600

> "Slone, Skip" wrote:

Having typed attributes in X.500/LDAP is one of the main advantages of 
these directories over more primitive data models such as DNS. However,
since I believe Subentries are Readable in X.500, the presence of a subentry
would prevent an object entry existing in the server with the same name.  It
is unfortunate that cn is the naming attribute for subentries and not something
more 'operational', since cn is frequently used as a naming attribute for 
object entries.  This means that an application which wants to create an object
entry named by cn must not only check to see whether there is an object 
entry with the same name, but also use a subentry-aware operation to check 
that there is no subentry with the same name.  This isn't worthwhile since 
applications which are bulk loading in object entries may not care about 
subentries if they are gateways from other protocols or data models.  
It would be FAR better to leverage this advantage and allow a more
administrator/operational-oriented naming attribute such as 'subentryname'
for naming subentries.  This attribute would be intended exclusively for
use by subentries and so would never conflict with object entries named
by cn.

Mark Wahl
Sun Microsystems Inc.