Subject: AW: Follow-up on Naming of Subentries

From: Fantou Patrick <[email-masked]>
Date: Wed, 12 Dec 2001 16:46:00 +0100

Hi Mark,

I cannot follow too much the reason of your requirement
to use another naming attribute as cn for a subentry.
In fact a good administrator will choose a name for a subentry which says something
about the content of the subentry, for instance
cn=subschemaSubentry or cn=accesscontrolSubentry,
independantly of the naming attribute used, and this , more than the naming attribute itself
would avoid conflicts.

Patrick Fantou
Siemens

> -----Ursprüngliche Nachricht-----
> Von: Mark Wahl [mailto:[email-masked]]
> Gesendet: Dienstag, 11. Dezember 2001 23:44
> An: Slone, Skip
> Cc: LDUP Mailing List ([email-masked])
> Betreff: Re: Follow-up on Naming of Subentries
> 
> 
> 
> > "Slone, Skip" wrote:
> >
> > 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.
> 
> 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.
>

---

From: Mark Wahl <[email-masked]>
Date: Wed, 12 Dec 2001 10:43:54 -0600

> independantly of the naming attribute used, and this , more than the naming attribute itself

The difficulty comes when subentries and object entries are being 
automatically created by two different applications.  These applications
would need to have some algorithmic ways of coming up with attribute values.
But this doesn't seem appropriate to use 'cn' for such things if there is 
some other attribute type that better describes what the application wants
to use.  Forcing them to use cn with a value which is perhaps some string
encoding of a GUID/UUID seems to counter the benefit of having typed RDNs.

Mark Wahl
Sun Microsystems Inc.