[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Attribute Name Length Bounds

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