RE: Attribute Name Length Bounds

[Peter Bachman <peterb@cequs.com>]

The generalized problem then is not related to the length, i take it, since
there's no requirement that a specific length, can or cannot represent the
information that's captured in schema, even if it causes problems of interoperability.

-pb

On Mon, 16 Jun 2003 09:41:46 -0600
"Jim Sermersheim" <jimse@novell.com> wrote:

>>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. 
>
>Well, I never said that, and it's not my intent at all.
>
>I agreed that this is a problem. I'm not suggesting that it be ignored.
>I'm also not suggesting that we get all extreme and put mandatory
>minimums on all sequences in the protocol/data model. 
>
>My intent is to ask that we view the general problem, and not just one
>aspect that happens to have reared its head recently.
>
>Jim
>
>
>>>> "Chris Apple" <capple@dsi-consulting.net> 6/14/03 4:00:29 PM >>>
>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
>
>