Re: Attribute Name Length Bounds

[Ryan Moats <rmoats@lemurnetworks.net>]

I can live with this.

Ryan

On Wed, Jun 25, 2003 at 10:42:58AM -0500, Larry S. Bartz wrote:
| 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 
| >   
| > 
| >