RE: Attribute Name Length Bounds

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 10:24 AM 6/13/2003, Richard V Huber wrote:
>In line with Larry Bartz' email mentioning RFC3383, how about:
>
>  To promote interoperability, server implementors SHOULD allow at
>  least 48 characters for attribute names and schema designers SHOULD
>  use attribute names which are no longer than 48 characters.

Let's look at each imperative separately.  First the latter:
  Schema designers SHOULD use attribute names which are no
  longer than 48 characters.

I think that BCP64, with the additions agreed upon in [Models],
basically covers this.  That is, BCP64bis will say that all
descriptors (excepting those in private name space) SHOULD be
registered and all descriptors in RFCs MUST be registered
in addition to say that descriptors longer than 48 may be
viewed as too long to register.

While not precisely a requirement upon all schema (because
it doesn't cover private name space elements), it certainly is
significant encouragement to schema designers to avoid
descriptors longer than 48.

If a more precise requirement is desired, I suggest this be
stated in a future "guidelines for schema developers" BCP
along with the many other requirements that likely should be
stated to schema developers.

Now the former:
  Server implementors SHOULD allow at least 48 characters for attribute names

Stating this in the LDAP TS is problematic as there is no
requirement (and rightly so) for server implementation to
support open-ended sets of attribute types.  While certainly
servers limit the sets of attribute types they support, they do
by many means.  Name length is just one factor.  From a protocol
interoperability stand point, this is not problem.

Basically, vendors have chosen to limit the suitability to
various markets.  That's their choice.

Now, what folks want is for vendors who claim to support
open-ended sets of attribute types to implement some minimum
set of requirements.  Or to say it another way, folks want
an applicability statement for a restricted domain of
applicability for which servers can claim to support.  That
domain being "servers which support open-ended sets of
attribute types" or maybe "general-purpose servers".

Note here that as no server is required to be a "general-purpose
server", we are talking about requirements for a restricted
domain of applicability.

As we've discussed in the past, those requirements are better
stating in a separate document which offers such an
applicability statement.

It's my view what is needed is two new documents:
        "Guidelines for LDAP schema developers"
        "Applicability Statement for general-purpose LDAP servers"

There is a fair amount of prior work in each of these areas.
Bruce long ago wrote an I-D on the former, and much of that
found its way in to my "Considerations for LDAP Extensions"
I-D (which covers schema as well as other kinds of extensions).
Also, the Open Group DIF is writing what are, in effect,
applicability statements for their directory certification
programs.

I think its best for these works to continue on an individual
basis.  LDAPBIS needs to remain (at least for now) focused on
delivering the "core" (technical) specification.

Kurt