Re: Attribute Name Length Bounds

[Ryan Moats <rmoats@lemurnetworks.net>]

On Mon, Jun 16, 2003 at 03:11:43PM -0500, Ryan Moats wrote:
| 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

ugh... that should be a *not* not a *NOT*.  stupid caps lock...

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