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