[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Attribute Name Length Bounds
Kurt,
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"
Or an "LDAP Implementation Guide". Either way, I agree that size limits
and such don't belong in the LDAPbis core specifications. It's pretty
clear that the core documents don't impose limits or even suggest that
there may be limits. The situation we have is that some implementors
have cut corners for their own convenience and been caught out.
I think the main message should always be "don't impose limits". Whatever
limits we might impose now are likely to eventually prove inadequate
and need revising. If we are going to suggest limits of some sort then
it's better if that is in an informational "guidelines" document than
in the technical specification.
Regards,
Steven
>
> 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
>
>
>