AW: Follow-up on Naming of Subentries

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 protected]]
> Gesendet: Dienstag, 11. Dezember 2001 23:44
> An: Slone, Skip
> Cc: LDUP Mailing List ([email protected])
> 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.
>