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

[Michael Ströder <[e-mail]>]

Andrew,

thanks for your feedback.

Andrew Findlay wrote:
> On Sun, Dec 16, 2012 at 08:45:10PM +0100, Michael Ströder wrote:
> 
>> Subject: New Version Notification for draft-stroeder-namedobject-00.txt
> 
>>    This document defines structural object classes that can be used when
>>    no other structural object class seems suitable.  Especially the
>>    object classes will give the possibility to associate a common name
>>    and a free-from description with the object.
> 
> In general I find it best to keep meaningful data *out* of DNs.

Me too...

> This allows the data in the entry to be updated without changing the
> DN, which is a very valuable property. 

Yupp.

> 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.)

> I would choose uniqueIdentifier over serialNumber because
> the latter has a specific meaning that may be required in the objects,
> whereas the meaning of uniqueIdentifier is 'for local definition'
> (RFC4524).

I concur. Changed 'serialNumber' to 'uniqueIdentifier'.

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

Since I'm not a native English speaker suggestions for a better wording are
very welcome.

> I realise that using opaque identifiers in DNs makes current LDAP tree
> browsers rather awkward. I regard this as a user-interface problem
> that is easily fixed by optionally showing displayName in place of the
> RDN.

I agree that this is a user-interface problem. And web2ldap handles that
pretty well anyway. ;-)

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.

> What about including 'owner' as a MAY attribute? Several of the
> structural classes in RFC4519 do this, and it is often useful when
> building access-control policies.

Funny enough I already thought about it. But 'owner' has pretty broad
semantics. Therefore I personally don't regard it as suitable for access
control and prefer to define custom attributes for it.

> If you expect these objects to be used to form drop-down menus or
> similar human-interface structures, then it may be appropriate to
> include an attribute specifically to control the ordering. This is
> getting a bit beyond the original stated purpose though, and is
> starting to impinge on RFC2293 as well.

I'd like to keep it really simple for now.
(Well, you remember what happened to your very simple I-D back in 2007. ;-)
But thanks for your reminder about RFC2293.

> Perhaps a separate I-D
> defining an auxiliary class for ordering would be better.

Looking forward to your I-D specifying it... ;-)

Ciao, Michael.