Subject: Re: Attribute Name Length Bounds

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 25 Jun 2003 02:10:12 -0600

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

---

From: "Larry S. Bartz" <[email-masked]>
Date: Wed, 25 Jun 2003 10:42:58 -0500

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

---

From: "Chris Apple" <[email-masked]>
Date: Wed, 25 Jun 2003 12:11:15 -0400

I completely agree that an upper limit would be bad.

The IANA considerations mentioned earlier in this thread do place
an upper limit on names which are to be registered. This doesn't
affect the protocol, but does make the registry less useful
than would be ideal.

If someone can point out plausible scenarios in which harm is caused
by adding a requirement of a SHOULD strength that attribute type names
and object class names of "at least 64 octets in length," I'll withdraw
the issue.

However, I think its time the bar gets raised with respect to
interoperability on this issue. Its fine to say (as suggested
earlier in this thread) that one implementation responding with
an error message or other indication of lack of support means
that its interoperable.

In the most basic sense of interoperability that is indeed true.
Its just not as useful as the suggested requirement of a minimally
supported length in the present operational environment for LDAPv3
implementations. As we move from PS to DS for LDAPv3, I think it
would be a good idea to improve the usefulness of interoperability.

We still have to have the more basic means of interoperability
(such as saying when you don't support something using appropriate
in-band methods). And we still have to improve that if needed.

But only doing that as you move from PS to DS doesn't help improve
the overall interoperability of the protocol as it is being used;
it simply preserves ipso facto interoperability. That doesn't seem
very useful to me as a user and service implementer.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked]

http://www.dsi-consulting.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jim Sermersheim
Sent: Wednesday, June 25, 2003 4:10 AM
To: [email-masked]; [email-masked]
Subject: Re: Attribute Name Length Bounds

Jim

 

 

 

regards,
John

John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade Avenue

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Jun 2003 10:30:05 -0700

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

Likewise.

---

From: Ryan Moats <[email-masked]>
Date: Wed, 25 Jun 2003 13:26:26 -0500

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

---

From: "Larry S. Bartz" <[email-masked]>
Date: Wed, 25 Jun 2003 15:54:19 -0500

Kurt D. Zeilenga wrote, On 06/25/03 12:30:
> Larry,
> 
> No server is required to support open-ended schema.

What is "open-ended schema"?

> Requirements

I won't/haven't presume(d) to say whether LDAP TS is the right
document to address this issue or not. It's just an issue right
now, as far as I'm concerned. But it's definitely an issue which
should be addressed by this WG.

> but are not required to otherwise support descriptors of any

What is the difference between "handle" and "support"? How does
that difference impinge upon the potential for one to implement
a schema which contains long names on a server which has a
relatively short name length limit?

>>and/or 'DESC' values which exceed 1024 characters in length."

[sound of light bulb clicking "ON"] Right. Both NAME and DESC
are optional fields of various schema component descriptors.
So by "open-ended schema" do you mean that they are optional
for servers to support as well as optional for implementors
to use? I haven't seen a server which didn't support NAME and
DESC, so it didn't occur to me that some servers might not
implement support for them.

Try this:

"Implementations which support the 'NAME' field of schema
descriptors MUST, at minimum, support values for that field
(such as attributetype names, objectclass names, matching rule
names, and the like) which are 1024 characters in length.
Implementations which support the 'DESC' field of schema descriptors
MUST, at minimum, support values for that field which are 1024
characters in length. Implementations MAY support 'NAME' field values
and/or 'DESC' field values which exceed 1024 characters in length."

-- 
--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  [email-masked]      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Jun 2003 15:04:22 -0700

>What is "open-ended schema"?

I used "open-ended schema" as a short hand for "an
open-ended set of schema elements."

The LDAP TS does not require servers to support any schema
element not defined in the LDAP TS.  In fact, the LDAP TS
does not even require servers to support all of the schema
elements defined in the LDAP TS.  Some servers support only
schema elements which they are specifically designed to support.
Other servers support schema specified by the administrator
(or user), normally with significant implementation-specific
constraints.  This latter breed of servers can be viewed as
supporting an open-ended set of schema elements.

The concern seems to be that some implementations have
constraints which you and others find to be quite limiting.
It's my view that servers are quite free to limited their
suitability in this fashion.

What folks seem to want is raise the bar on servers which
support open-ended sets of schema elements.  That's quite
a reasonable think to want to do.

>document to address this issue or not.

My point is that the LDAP TS is not the right place to address
this issue.  It's seems to me that this name length issue is one
of many similar issues facing schema designers as well as
those trying to determine whose server to deploy.  It seems
like the right document would be some sort of applicability
statement for servers intending to support open-ended sets
of schema and/or document providing schema design guidelines,
and/or a document providing implementation guidelines.

>What is the difference between "handle" and "support"?

As I used them, handle means that the server is capable
of parsing the client's PDU and to take any one of the
actions allowed it by the technical specification.  Support
means that the server would actually recognize the descriptor
as being equivalent to one of the object identifiers it
recognizes and supports.

Or, to say it with an example, a server which doesn't
support 'createTimestamp' should still be able to handle
'createTimestamp' appearing in PDUs in a manner consistent
with the LDAP TS (that is, treat 'createTimestamp' as
referring to an unrecognized attribute type).

>How does

'handle' ensures protocol interoperability.

I like to note that regardless of what attribute name limit
one might add to the LDAP TS, that limit cannot rightly be
viewed as requiring servers to support open-ended sets of schema
elements in any particular manner.  Aside from not being
required to support open-ended sets of schema elements at all,
servers are free to restrict the the sets of schema elements
by any means (including very arbitrary ones).  For example,
the statement would not prevent a server supporting open-ended
sets of schema elements from not supporting attribute types
names starting with 'x-'.

>So by "open-ended schema" do you mean..

See above.

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 26 Jun 2003 14:05:08 +1000

Larry,

> for LDAP's "DESC" stanzas as well.

The length constraint of 1024 in X.500 is non-normative. It only carries
the weight of a "suggestion". Implementors are free to impose any limit
they like, less or greater.

Regards,
Steven