Subject: Attribute Name Length Bounds

From: John Strassner <[email-masked]>
Date: Tue, 24 Jun 2003 22:08:22 -0600

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: [email-masked]