Re: Attribute Name Length Bounds

["Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>]

As a schema implementer, I require some assurance that Directory
servers will uniformly support schema specifications which conform
to some kind of consensus-based constraints. As a schema designer,
I require the flexibility of assigning meaningful (and sometimes
long) names to schema components.

I have had the same experience of which Chris Apple wrote when he
started this thread. It is obvious that since no constraints are
specified in standards documents, Directory server providers are
free to choose and set their own limits. This leads directly to
interoperability problems. The problems are the direct result of
underspecification. The non-spec leads to arbitrary implementation.

I don't think it is reasonable to expect Directory implementations
to support length-limitless names for the schema's object identifiers.
I don't code Directory server software, but I expect that a
limitless spec is an invitation to buffer overflow problems and/or
resource exhaustion.

In my previous contributions to this thread, I suggested that the
RFC 3383 might serve as a guide, since consensus had already been
achieved. That document specifies a limit on names of 48 characters.
Considering other contributions to this thread, I don't think
RFC 3383's 48 characters is enough. [As an aside, note that Kurt
has just published a draft intended to replace RFC 3383. These
considerations may impact the discussion of that draft, as well.]

Instead, consider X.501. My reading of the 4th Edition indicates
a length limit of 1024 characters is specified. Here is a pertinent
excerpt from Annex C of X.501:

<edited quote>
DITStructureRuleDescription ::= SEQUENCE {
 COMPONENTS OF DITStructureRule,
 name [1] SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL,
 description DirectoryString { ub-schema } OPTIONAL,
 obsolete BOOLEAN DEFAULT FALSE }

DITContentRuleDescription ::= SEQUENCE {
 COMPONENTS OF DITContentRule,
 name [4] SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL,
 description DirectoryString { ub-schema } OPTIONAL,
 obsolete BOOLEAN DEFAULT FALSE }

MatchingRuleDescription ::= SEQUENCE {
 identifier MATCHING-RULE.&id,
 name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL,
 description DirectoryString { ub-schema } OPTIONAL,
 obsolete BOOLEAN DEFAULT FALSE,
 information [0] DirectoryString { ub-schema } OPTIONAL }

AttributeTypeDescription ::= SEQUENCE {
 identifier ATTRIBUTE.&id,
 name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL,
 description DirectoryString { ub-schema } OPTIONAL,
 obsolete BOOLEAN DEFAULT FALSE,
 information [0] AttributeTypeInformation }

ObjectClassDescription ::= SEQUENCE {
 identifier OBJECT-CLASS.&id,
 name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL,
 description DirectoryString { ub-schema } OPTIONAL,
 obsolete BOOLEAN DEFAULT FALSE,
 information [0] ObjectClassInformation }

NameFormDescription ::= SEQUENCE {
 identifier NAME-FORM.&id,
 name SET SIZE (1..MAX) OF DirectoryString { ub-schema } OPTIONAL,
 description DirectoryString { ub-schema } OPTIONAL,
 obsolete BOOLEAN DEFAULT FALSE,
 information [0] NameFormInformation }
</edited quote>

Note that the "name" component of each is specified with an upper
bound of "ub-schema". Note that Annex C of X.520 4th Edition defines
"ub-schema" as:

<edited quote>
ub-schema INTEGER ::= 1024
</edited quote>

Can we agree that these considerations must apply to all of LDAP's
object identifier descriptors, including attributetype names,
objectclass names, matching rule names, etc? I suggest that we further
follow X.501's lead and provide a length constraint of 1024 chars
for LDAP's "DESC" stanzas as well.

How about this language?

"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. 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."

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 
>   
>
>