Re: [ldapext] Fwd: New Version Notification for draft-stroeder-namedobject-00.txt

[Andrew Findlay <[e-mail]>]

On Mon, Jan 07, 2013 at 09:02:10PM +0100, Michael Ströder wrote:

> > I would therefore prefer *not*
> > to use CN as the naming attribute. I propose including
> > uniqueIdentifier as a MUST attribute and strongly suggesting its use
> > as the RDN.
> > [..]
> > I would suggest advising the use of opaque values for
> > uniqueIdentifier to make sure that the DN never has to be modified.
> 
> While I strongly agree with the basic idea I won't write it in the I-D like
> this to preserve backwards-compability with [I-D.howard-namedobject] which is
> already used in some implementations. (I did not preserve the OID though.)

The original I-D made CN mandatory in the text but optional in the
schema definition. Looking around for things that use namedObject, I
found:

1	SuSE's YaST version of the RFC2307bis schema where they apparently use
	namedObject for empty groups and then change the object class to
	groupOfNames when the group gets a member!

2	ForgeRock inculude the I-D.howard-namedobject definition in
	their core schema

3	OpenLDAP does not ever seem to have distributed a definition
	for this class

4	Gosa includes exactly the same RFC2307bis schema that SuSE uses.

5	Kolab seems to have an incompatible derivative using the
	original OID and a new name:
	olcObjectClasses: ( 1.3.6.1.4.1.5322.13.1.1 NAME 'kolabNamedObject' SUP top STRUCTURAL MAY (cn $ ou) )

There is at least one other definition of namedObject floating around
though I don't know whether it has ever been used:

	http://tools.ietf.org/id/draft-furuseth-ldap-untypedobject-02.txt

That one permits a wide range of attributes but expects you to use
just one of them in the entry.

If we assume that only the I-D.howard-namedobject version is actually
used in the wild, then one option for preserving compatibility would be:

( 1.3.6.1.4.1.5427.1.389.6.20 NAME 'namedObject' SUP top STRUCTURAL
  MAY ( uniqueIdentifier $ cn $ displayName $ description ) )

> For the next version of the I-D this text is meant to express a preference for
> using 'uniqueIdentifier' over 'cn' to form the RDN:
> 
>     If the optional attribute 'uniqueIdentifier' contains a value it
>     SHOULD be used to form the RDN of the entry.

Perhaps add:
      There are advantages to using opaque (meaningless) values in the
      RDN of the entry, as this allows all meaningful attributes to be
      modified without changing the RDN.

>     Otherwise the mandantory attribute 'cn' SHOULD be used to form
>     the RDN of the entry if there are no other appropriate naming
>     attributes available.
>     Other attributes allowed by auxiliary classes also MAY be used for
>     naming purposes.

This would still permit the traditional use of the objectclass, but
would provide a pointer towards better design practice.

> But 'displayName' is not really widely used and only defined in RFC 2798. So I
> prefer 'cn' over 'displayName' also because of backward-compability to
> [I-D.howard-namedobject]. But I agree that 'displayName' being SINGLE-VALUE is
> an advantage.

RFC2798 defines inetOrgPerson, so displayName is almost certain to be
available in every deployed LDAP server. The only objection that I can
see is that the attribute description refers to 'a person':

  ( 2.16.840.1.113730.3.1.241
    NAME 'displayName'
    DESC 'preferred name of a person to be used when displaying entries'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE )

I have used displayName for years in all sorts of entries because its
purpose and usage is very clear.

I am not sure that it is necessary to say anything about how to
display lists of items, but if you want to keep that in, how about:

   LDAP clients displaying entries of these object classes
   SHOULD take the title of the entry from the displayName attribute if
   available, otherwise from the cn or other appropriate attribute.
   The value of the uniqueIdentifier attribute will not usually be
   useful to a human user.

> > Perhaps a separate I-D
> > defining an auxiliary class for ordering would be better.
> 
> Looking forward to your I-D specifying it... ;-)

I will give it some thought!

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                [phone]     |
-----------------------------------------------------------------------