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

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.

These classes could certainly be useful, but I think the advice
attached to them could be improved.

In general I find it best to keep meaningful data *out* of DNs.
This allows the data in the entry to be updated without changing the
DN, which is a very valuable property. 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 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 would suggest advising the use of opaque values for
uniqueIdentifier to make sure that the DN never has to be modified.

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. Directory designers also have the option of giving
uniqueIdentifier the same value as cn or displayName, but that
compromises the value of using uniqueIdentifier in the first place.

I would support the inclusion of CN because it is commonly used for
search. However I would not make it mandatory and I would not suggest
its use for displaying select lists etc. CN is potentially
multi-valued to support search, so it is not suitable for unambiguous
display in lists. displayName should be included in the class and used
for that purpose. I normally make displayName mandatory, but that
might not be appropriate here given the broad application of these
classes. [ Although displayName is SINGLE-VALUE, it does support
language tags so any menu built from this attribute can be properly
internationalised and localised ].

In schema definition terms, I am suggesting this:

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

I have left CN in MUST because the class is called 'namedObject',
but would probably be happier if it were in MAY.

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.

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. Perhaps a separate I-D
defining an auxiliary class for ordering would be better.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------