RE: Attribute Name Length Bounds

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

I would be fine with it if the scope was attribute type names
and object class names.

What is beginning to concern me is that your words imply that
it is inappropriate to address known interoperability issues
in preparation for moving to Draft Standard. It's true that it
has become a known problem because of recent work I've done.
The timing doesn't diminish the importance of discussing it
in this forum; nor does it diminish the negative impact it will
have on deploying services using the protocol in the field if
there isn't some requirement addressing this particular known
issue.

I'm sure it's a good idea to look at the problem in a general
way. I'm also sure that most users would appreciate
tempering pure technical merit with pragmatic deployment
concerns along the way.

The idea of addressing this particular issue with a requirement
seems to have some supporters and some folks who don't think its
a good idea. But there hasn't been a lot of discussion about
which LDAPBIS deliverable this might apply to.

Notice that I actually stated that I didn't know where to even
suggest its inclusion at the start of this thread. Nor do I at
this time.

That is perhaps a question that needs to be asked and answered
explicitly. So consider it asked. Where do folks think such a
requirement belongs? In one of the LDAPBIS deliverables? Or
somewhere else (and where if that's the case)?

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: Saturday, June 14, 2003 2:16 PM
To: ietf-ldapbis@OpenLDAP.org
Subject: RE: Attribute Name Length Bounds


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

This is exactly my concern. It seems coincidental that you are seeing
this problem, we are edititng the specification, so you see a chance to
fix this problem. If you hadn't seen this problem at this particular
time, and the spec got progressed without this change, then I suspect
the problem would be addressed in some other way (one of those talked
about earlier in the thread).

Given this concern, I decided to have a look at some of the other
potential 'problems' that are the same as this one.

If, instead of this problem, you found that some servers limited DNs to
32 characters, we might be having that conversation instead of this one.
I don't see the difference between schema lenghts and some of the other
sequences listed in this thread. If you want to draw the line at those
things which have IANA considerations, then we throw out sizes on other
schema elements, and add in sizes on other things (like SASL mechanism).
What's happenning here is a jump over to the IANA reasoning, then a hop
over to a "similar elements" reasoning.

To paraphase, my concern is that we're jumping on a problem just
because someone happened to experience it, without looking at it in a
general way. 

If we add this change, it sets a precedence for a class of instructions
that was never part of the original spec. We shouldn't do this in such
an isolated way. That only makes future readers scratch their heads
wondering at the inconsistency.

I don't understand why this can't be specified in an application
profile document. I would say that there's a class of application that
must add to (extend) the standard LDAP schema. For LDAP servers to
service this class of applications, then they should handle reasonable
schema name lengths. I don't think the LDAP spec even says that an LDAP
server needs to allow its schema to be extended, only that it must
support certain standard schema.

Jim

>>> "Chris Apple" <capple@dsi-consulting.net> 6/13/03 9:16:48 PM >>>
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