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

From: Michael Ströder <[email-masked]>
Date: Wed, 02 Jan 2013 16:29:09 +0100

Manuel Gaupp wrote:
> Michael Ströder wrote:
>> Please review this draft intended to be published as informational RFC.
> 
> Section 2 ends with the following requirement:
> 
>    LDAP clients displaying a list of entries of these object classes
>    should use mandantory attribute 'cn' to display select lists, hyper-
>    links etc.
> 
> I think this requirement is a bit too specific for such generic object
> classes. In my opinion, default behavior should be to use the attribute(s)
> from the RDN, any other behavior should depend on the specific use case. 

I expected this text to provoke some discussion. ;-)

But I'd like to encourage deployers to think of sufficiently descriptive
common names stored in attribute 'cn' within a given context. Note that
'namedObject' entries are not really usable without auxiliary object class(es)
which limit context and thus the meaningful name space for 'cn'.

> And, think of multivalued RDNs: "cn=namedPolicyEntry+serialNumber=0815" and
> "cn=namedPolicyEntry+serialNumber=4711" would both be listed as
> "namedPolicyEntry" according to this requirement.

I know that some people use DNs like in your example above to make DNs itself
more readable.

But personally I think that multi-valued RDNs really suck because you have to
rename an entry in case one of the characteristic attributes change which is
more effort when maintaing data.
And I saw too many software components failing to handle them correctly.

So one could understand the recommendation in the I-D also to discourage use
of multi-valued RDNs. ;-)

> Section 4 contains the following definition:
>    The OID arc used for the object class defintions is: iso(1) org(3)
>    dod(6) internet(1) private(4) enter-prise(1) stroeder.com(5427)
>    objectClasses(6)
> This does not match the OIDs used in the object class definitions
> (1.3.6.1.4.1.5427.6 versus 1.3.6.1.4.1.5427.1.389.6).

Fixed. Thanks!

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Mon, 7 Jan 2013 12:30:45 +0000

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

---

From: Michael Ströder <[email-masked]>
Date: Mon, 07 Jan 2013 21:02:10 +0100

Andrew,

thanks for your feedback.

> In general I find it best to keep meaningful data *out* of DNs.

Me too...

> DN, which is a very valuable property. 

Yupp.

> I would therefore prefer *not*
> as the RDN.
> [..]
> I would suggest advising the use of opaque values for

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

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

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

> 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

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

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Tue, 8 Jan 2013 13:18:18 +0000

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

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

>     Other attributes allowed by auxiliary classes also MAY be used for

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

> [I-D.howard-namedobject]. But I agree that 'displayName' being SINGLE-VALUE is

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.

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

I will give it some thought!

Andrew

---

From: Linus van Geuns <[email-masked]>
Date: Wed, 9 Jan 2013 16:33:57 +0100

Hey Michael,

Your draft (draft-stroeder-namedobject-01) basically defines a common,
structural object class to be combined with arbitrary auxiliary classes
established e.g. in other standards.
This could drastically reduce the number of structural ('non-combinable')
object classes defined for public use. This in turn might reduce the number
of custom classes to combine several structural classes from public schema
definitions.

I did not yet find any satisfactory rationale for specifying the kind of a
class within the object class definition anyways. IMHO, the structural
object class of an entry - if required at all - should be defined during
instantiation of that particular entry and may be governed by structure
rules.

Since LDAPv3 is the current and proposed standard, I think your proposal is
the best approach we have regarding that issue.

As attribute 'cn' is multi-valued and ambiguous entry names in
user-interfaces are pretty annoying, I would like to restrict your
recommendation on string-representation of entries in chapter 2 as well.

<proposal >
In case that any value of mandatory attribute 'cn' is used to form the RDN
of an entry of these object classes, LDAP-clients SHOULD use that
distinguished value for string-representation of the particular entry (e.g.
within user interfaces). Any additional AVAs present in such a RDN SHOULD
also be included in the entries string-representation, indicating the
attribute type of each additional value.
</proposal>

As this recommendation is pretty generic, it might fit in more smoothly
into a more generic LDAP client BCP. :o)

Regarding to your rationale for class 'namedPolicy' in chapter 2.2:
I dont understand how combining policy-related auxiliary classes with class
'namedObject' would restrict this class in any way.

Regards, Linus