Re: Attribute Name Length Bounds

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

Larry,

No server is required to support open-ended schema.  Requirements
for such servers supporting open-ended schema don't belong in the
LDAP TS, they belong in an applicability statement for servers
supporting open-ended schema.  The "assurance" is then provided
by developers who claim their server adheres to this applicability
statement.

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.

Your suggestion would not only require servers to otherwise
support names which they need not, but would imply that a
server need not handle names longer than 1024.  The former
is problematic because no server is required to support
open-ended schema and the latter is problematic as servers
need to be able to handle all legal PDUs to avoid protocol
interoperability problems.

>Implementations MUST, at minimum, support 'DESC' or
>description values which are 1024 characters in length.
>Implementations MAY support object identifier descriptors
>and/or 'DESC' values which exceed 1024 characters in length."

Likewise.


>Larry
>
>
>Jim Sermersheim wrote, On 06/25/03 03:10:
>>I agree. I don't like adding an upper limit.
>>Right now, the LDAP TS doesn't specify any limit (an attribute name can
>>be from 1 to infinite in length). The TS neither limits the length, nor
>>allows a protocol peer to ignore data exceeding any length.
>>The only actual problem I've heard articulated is that it doesn't
>>explicitly forbid a protocol peer from ignoring data exceeding any
>>length. Some argue that such a specification is redundant and not needed
>>(do we really need to state in every protocol specification that
>>protocol peers MUST NOT arbitrarily truncate PDU data?)
>>My question at this point is: Do we need a statement like this? Is
>>there language (or absence of language) that made an implementor think
>>they were following the TS when they chose to ignore the 33rd and higher
>>octets in attribute names passed in protocol?
>>If this is just a case of an implementation not allowing (by means of
>>returning an error) more than 32 characters for attribute names, it
>>seems like an application issue. It's no different from an
>>implementation returning an error for DNs that exceed 32 characters, or
>>a host of other similar implementation-imposed limitations.
>>Jim
>>
>>
>>>>>John Strassner <John.Strassner@intelliden.com> 6/24/03 10:08:22 PM
>>Since I have rather strong views on this, I thought I would carefully
>>read
>>the thread and then provide some insight as to how decisions made in
>>LDAPbis
>>could affect various fora and standards bodies.
>> 
>>I've now gone through the thread twice, and still have the same
>>conclusion -
>>prescribing an attribute name length bound is BAD.
>> 
>>I'm not going to rehash any of the other arguments, because my feeling
>>is
>>that the WG is at somewhat of an impasse here. However, I will present
>>an
>>argument with new data, which is based on **users** wishing to develop
>>directory schemata and finding that existing implementations have
>>severe
>>interoperability problems.
>> 
>>There are numerous standards bodies and fora, ranging from the
>>TeleManagement Forum to the DMTF to 3GPP to a host of XML and Web
>>Services
>>efforts, that have as part of their standards relatively long names.
>>For
>>those that are using UML (or UML-like) approaches, this takes the form
>>of
>>very long (> 64 characters is common) class, attribute, and
>>relationship
>>(e.g., association, aggregation, composition, etc.) names. The basic
>>way
>>that many of these schemata are designed uses a standard and simple
>>method
>>to generate the name of relationships: <object1><verb><object2>. Note
>>that
>>the order may also be <verb><object1><object2>.
>> 
>>Thus, whether a class or an attribute name could conceivably be
>>shortened,
>>it is almost certain that the relationship won't be able to be
>>shortened a
>>sufficient amount to do any good.
>> 
>>More importantly, however, as a schema designer, I find it
>>unaccceptable
>>that my schema has to go through some bizarre machinations when being
>>transformed from an information model to a data model just so it has a
>>prayer of being implemented in a directory. This is a great way to
>>encourage
>>people NOT to use a directory.
>> 
>>The mapping is difficult enough as it is - coming up with some
>>difficult
>>alias schemes, or methodology for name shortening, is not conformant to
>>the
>>basic schema that was agreed to by the standard body or fora in the
>>first
>>place.
>> 
>>Furthermore, once one "buys into" any type of translation mechanism to
>>produce different names, it is guaranteed to cause interoperability
>>problems, simply because it is too hard to guarantee that two
>>different
>>implementations will apply the same rule to produce the same name.
>> 
>>The examples listed above cover a very large body of work in different
>>disciplines. Restricting name length to some arbitrary limit is
>>inherently
>>bad, as it flies in the face of the standards bodies and fora that are
>>trying to use directories in the first place. They also exacerbate
>>existing
>>interoperability problems.
>> 
>>This WG might not have identified issues such as these explicitly as
>>part of
>>its charter, but it should consider them, since its fundamental purpose
>>is
>>to produce a draft standard. That requires interoperability.
>> 
>>Please, let's not ruin LDAP as it starts to mature.
>> 
>>regards,
>>John
>>John Strassner
>>Chief Strategy Officer
>>Intelliden Corporation
>>90 South Cascade Avenue
>>Colorado Springs, CO  80903  USA
>>phone: +1.719.785.0648
>>  FAX: +1.719.785.0644
>>email: john.strassner@intelliden.com   
>> 
>
>