Re: Attribute Name Length Bounds

[Ryan Moats <rmoats@lemurnetworks.net>]

Kurt-

It is *NOT* clear to me whether you are speaking as co-chair or
something else or both.  Can you please note (going forward)
which comments are being made with which hat on?

Thanks,
Ryan

On Mon, Jun 16, 2003 at 12:50:12PM -0700, Kurt D. Zeilenga wrote:
| 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
| 
|