[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Attribute Name Length Bounds
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
|
|