Re: Attribute Name Length Bounds

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:54 PM 6/25/2003, Larry S. Bartz wrote:
>Kurt D. Zeilenga wrote, On 06/25/03 12:30:
>>No server is required to support open-ended schema.
>What is "open-ended schema"?

I used "open-ended schema" as a short hand for "an
open-ended set of schema elements."

The LDAP TS does not require servers to support any schema
element not defined in the LDAP TS.  In fact, the LDAP TS
does not even require servers to support all of the schema
elements defined in the LDAP TS.  Some servers support only
schema elements which they are specifically designed to support.
Other servers support schema specified by the administrator
(or user), normally with significant implementation-specific
constraints.  This latter breed of servers can be viewed as
supporting an open-ended set of schema elements.

The concern seems to be that some implementations have
constraints which you and others find to be quite limiting.
It's my view that servers are quite free to limited their
suitability in this fashion.

What folks seem to want is raise the bar on servers which
support open-ended sets of schema elements.  That's quite
a reasonable think to want to do.

>I won't/haven't presume(d) to say whether LDAP TS is the right
>document to address this issue or not.

My point is that the LDAP TS is not the right place to address
this issue.  It's seems to me that this name length issue is one
of many similar issues facing schema designers as well as
those trying to determine whose server to deploy.  It seems
like the right document would be some sort of applicability
statement for servers intending to support open-ended sets
of schema and/or document providing schema design guidelines,
and/or a document providing implementation guidelines.

>>At 08:42 AM 6/25/2003, Larry S. Bartz wrote:
>>
>>>"Implementations MUST, at minimum, support object identifier
>>>descriptors (such as attributetype names, objectclass names,
>>>matching rule names, and the like) which are 1024 characters
>>>in length.
>>
>>Today, servers must be able to handle descriptors of any length
>>but are not required to otherwise support descriptors of any
>>length.
>
>What is the difference between "handle" and "support"?

As I used them, handle means that the server is capable
of parsing the client's PDU and to take any one of the
actions allowed it by the technical specification.  Support
means that the server would actually recognize the descriptor
as being equivalent to one of the object identifiers it
recognizes and supports.

Or, to say it with an example, a server which doesn't
support 'createTimestamp' should still be able to handle
'createTimestamp' appearing in PDUs in a manner consistent
with the LDAP TS (that is, treat 'createTimestamp' as
referring to an unrecognized attribute type).

>How does
>that difference impinge upon the potential for one to implement
>a schema which contains long names on a server which has a
>relatively short name length limit?

'handle' ensures protocol interoperability.

I like to note that regardless of what attribute name limit
one might add to the LDAP TS, that limit cannot rightly be
viewed as requiring servers to support open-ended sets of schema
elements in any particular manner.  Aside from not being
required to support open-ended sets of schema elements at all,
servers are free to restrict the the sets of schema elements
by any means (including very arbitrary ones).  For example,
the statement would not prevent a server supporting open-ended
sets of schema elements from not supporting attribute types
names starting with 'x-'.

>So by "open-ended schema" do you mean..

See above.