RE: Attribute Name Length Bounds

["Chris Apple" <capple@dsi-consulting.net>]

My intended scope was names for schema elements such as
attribute types, object class identifiers, attribute
syntaxes, matching rules, and anything else that might
be mapped to an OID with an associated, registered name.

Given that there are IANA considerations for the registration
of at least some of those types of schema elements, I don't
think I'm proposing anything that is outrageous or unreasonable.

I absolutely agree that most of the examples you gave should be
handled in the context of profiling LDAPv3 DIT structure,
Operations, Service Model, etc., for specific applications.

I'm of the opinion that this particular minimum size requirement
is of more general use than a specific application profile. I've
already given two different examples where this is an issue.
I'll repeat them here along with a third:

	- DEN
	- LDAPv3 mappings of the DMTF CIM
	- The Open Group's Mobility and Directory (MaD) Schema
	  (this will be publicly presented at the Burton Group's
	   Catalyst meeting in July 2003 - but basically its an
	   information model for directory-enabled mobility
	   management)

Those are all different application contexts. Each has a need
for attribute type names that are longer than the maximum
attribute length supported by some LDAPv3-compliant implementations.

Thus it is generally valuable to have a minimum length requirement
for at least attribute type names and object class identifiers. By
extension it also seems generally valuable to have the same sort of
minimum supported length for names of matching rules and attribute
syntaxes.

I wouldn't take it further than that because I don't have real world
examples that justify doing so.

However, to accommodate the 3 schema specifications above in
a general way, I do believe its justified. Specifying such
a minimum schema element name length requirement would solve an
interoperability problem related to using the protocol in the real
world in at least three different and very significant application
contexts. I think that's very much in line with the intent of
progressing to Draft Standard. If we were to waive our hands about
this and say, it means that we are interoperable if we just say
we don't understand something that's been sent to us, we haven't
actually helped the users with a relatively costly interoperability
problem.

I don't think hand waving makes for good standards when
there's a need such as this that crosses multiple application
contexts. Especially when such a requirement can scoped so
that it doesn't cause the kind of "here a limit, there a limit,
everywhere a limit" rat hole that some of the most recent postings
implied might happen.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:capple@dsi-consulting.net

http://www.dsi-consulting.com

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Jim Sermersheim
Sent: Friday, June 13, 2003 6:43 PM
To: ietf-ldapbis@OpenLDAP.org
Subject: Re: Attribute Name Length Bounds


I'm still a little fuzzy on the scope of this discussion.

The ASN.1 for attribute names is an unbounded OCTET STRING. 

This discussion seems to be saying "even though the protocol says the
size is unlimited (well, limited to a ber length), we want to be more
explicit and require protocols peers to handle some minimum size".

What else does this discussion apply to?
- LDAPDN (how long of a DN am I required to handle?)
- RelativeLDAPDN 
- AttributeValue/AssertionValue (I note that the current len descriptor
on attributes is a 'suggested minimum')
- MatchingRuleId
- LDAPResult.diagnosticMessage
- LDAPURL (I suppose enough for a minimal scheme and delimiters is
implied)
- SASL mechanism (implied 1 to 20)
- SASL credentials
- LDAPOID
- control/extendedValue
- simple password

AFAIK, today these all have a max-ber-len max. and no mandatory minimum
is explicitly required to be supported.

Jim