Subject: Re: Attribute Name Length Bounds

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 13 Jun 2003 01:52:10 -0600

As far as I know, neither [Models] nor [Protocol] limits the lenght of
attribute names. Any limitiation in a specific implementation is imposed
by that implementation, not by the spec, so I'm not sure we can do
anything about it here.

Obviously no server allows an unlimited length, as they are all
limiited if by nothing more than available memory. I'm not sure if this
fits into an implementation report. It seems more appropriate for a
certification/branding program. Other than that, it seems like a valid
defect to raise with those implementors who restrict to unreasonable
limits.

Jim

>>> "Chris Apple" <[email-masked]> 6/13/03 1:28:54 AM >>>
I have encountered a problem while attempting to extend the basic
schema
of several different LDAPv3 server implementations. Specifically, some
of
them place restrictions on the length of attribute names. In one case,
the attribute name length restriction is rather short, too short to
make it possible for it to distinguish between two different attribute
names with the same character string as a prefix. Take a look at the
DEN schema for examples of such attribute names.

So far, I cannot find a requirement in any LDAP-related RFC or I-D
that addresses the issue of attribute name length bounds.

This means that you cannot take the same schema specification and
apply
it verbatim to different LDAPv3 server implementations and to me
represents an inhibitor to interoperability of clients and servers
that have different attribute length restrictions/constraints/etc.

However, I am not sure where to suggest adding such a requirement
to clarify the nature of the problem to implementers so that this
interoperability impact can be minimized.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked] 

http://www.dsi-consulting.com

---

From: [email-masked] (Mark C Smith)
Date: Fri, 13 Jun 2003 09:26:12 -0400

> defect to raise with those implementors who restrict to unreasonable

I agree. I tried to come up with text that we could add to [Models] or 
[Protocols] that would encourage implementors to not impose arbitrary, 
short limits... but I am not sure how to word such a requirement so it 
is meaningful. This is an interesting interoperability problem though.

-Mark

---

From: "Larry S. Bartz" <[email-masked]>
Date: Fri, 13 Jun 2003 09:48:28 -0500

> is meaningful. This is an interesting interoperability problem though.

Perhaps reference to "3.3. Object Identifier Descriptors" of RFC 3383
"IANA Considerations for LDAP" would be helpful. It says,

"While the protocol places no maximum length restriction upon
  descriptors, they should be short.  Descriptors longer than 48
  characters may be viewed as too long to register."

There was obviously consensus in this WG regarding that length and
that language.

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

---

From: "Chris Apple" <[email-masked]>
Date: Fri, 13 Jun 2003 11:44:27 -0400

I was thinking more along the lines of a minimum bound in one of the
LDAPv3 Draft Standard documents.

How about this for a requirement? 

"Implementations MUST support attribute names that are at least 32
characters in length."

It seems like a simple one without a lot of baggage to me. But if anyone
thinks there's a good reason not to include it, I'd like to know what
that is.

I have no strong opinions on an upper bound.

I do realize that there is a work-around for this problem in most cases.
You can create a shorter attribute name and then use the intended attribute
name as an alias. But this gets to be a bit complicated when rolling out
services that use schema designed with longer attribute names.

You have to perform testing to see what each implementation in question
supports and then create aliases matching up with the shortest supported
attribute name length.

As a service implementer, that's an awfully expensive interoperability
hoop to have to jump through if I'm using a technology that is soon to
be based on a Draft Standard.

I realize that someone might also want a larger attribute name length
but there seems to already be some restriction with respect to what may be
allowable from an IANA registration perspective. I'm not questioning that
because 48 characters for an upper bound seems reasonable to me.

DSI Consulting, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Larry S. Bartz
Sent: Friday, June 13, 2003 10:48 AM
To: [email-masked]
Subject: Re: Attribute Name Length Bounds

---

From: "Chris Apple" <[email-masked]>
Date: Fri, 13 Jun 2003 11:56:11 -0400

I could certainly raise it within an interoperability/certification
program like that which The Open Group has. But generally, the certification
tests follow the specs. So unless there's a requirement relating to this
issue in the specs, it is unlikely to be adopted as a certification
requirement.

I think the interoperability problem I encountered is caused by lack
of a requirement specifying a lower bound. Its basically a grey area
as the specs stand now.

My interpretation of the LDAPBIS charter is that this is the place where
grey areas are to be clarified in preparation for progressing LDAPv3
to Draft Standard. In reminding myself what Draft Standard means (RFC 2026,
Section 4.1.2), clarifying grey areas affecting interoperability would
seem to fit within the scope of the LDABBIS WG Charter.

The group may not agree with my position on this particular issue,
but this does appear to be the appropriate place to raise it.

DSI Consulting, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jim Sermersheim
Sent: Friday, June 13, 2003 3:52 AM
To: [email-masked]
Subject: Re: Attribute Name Length Bounds

Jim

DSI Consulting, Inc.

---

From: "Larry S. Bartz" <[email-masked]>
Date: Fri, 13 Jun 2003 12:28:05 -0500

> "Implementations MUST support attribute names that are at least 32

How about 48? If IANA's ub is 48, then implementations could reasonably
expect to see names of that length. All products and implementations
should be prepared to support that.

Further, the requirement should not be limited to attributetype names.
The spec in RFC 3383 covers all object identifier descriptors, which
includes attributetype names, objectclass names, matching rule names,
etc.

How about this?

"Implementations MUST support object identifier descriptors (such as
attributetype names, objectclass names, matching rule names, and the
like) which are at least 48 characters in length."

Larry

---

From: "Chris Apple" <[email-masked]>
Date: Fri, 13 Jun 2003 13:32:35 -0400

Works for me.

DSI Consulting, Inc.

-----Original Message-----
From: Larry S. Bartz [mailto:[email-masked]] 
Sent: Friday, June 13, 2003 1:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Attribute Name Length Bounds

How about this?

Larry

---

From: Kathy Dally <[email-masked]>
Date: Fri, 13 Jun 2003 13:59:31 -0400

Hi All!

Saying all object identifier descriptors is ok.  The 48 limit is ok. 
However, I think we do need to recognize both the sending and receiving
cases.  How's this:

   "To promote interoperability, server implementations SHOULD support
receiving object identifier descriptors (such as. attributetype names,
objectclass names, matching rule names, and the like), which are at
least 48 characters in length and MUST send object identifier
descriptors that are no longer than 48 characters.  Schema designers
SHOULD use object identifier descriptors that are no longer than 48
characters."

Thanks,
Kathy

---

From: "Chris Apple" <[email-masked]>
Date: Fri, 13 Jun 2003 14:48:47 -0400

If you don't support receiving them at least that long, sweeping the SHOULD
under the carpet, as is every implementer's prerogative, would make the
weight
of the sending MUST irrelevant from an interoperability perspective. You
could still have implementations sending out attribute names that are 48
characters in length to an implementation that doesn't choose to support
the minimum length specified in the receiving case.

Why you would do this as an implementer, I don't know. But it is possible
given the wording you propose for an implementer to claim conformance,
but still have the same interoperability issue arise if the receiving
case is covered by a SHOULD requirement.

Reversing the sense doesn't help matters much, but also doesn't make it
much worse than the original proposal to specify a case for general support
and
stating that it is a MUST and a lower bound, regardless of
sending/receiving.

So I guess it comes down to whichever wording seems clearer to implementers
if the SHOULD/MUST sense is reversed in your proposal.

DSI Consulting, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Kathy Dally
Sent: Friday, June 13, 2003 2:00 PM
To: Larry S. Bartz
Cc: [email-masked]; [email-masked]
Subject: Re: Attribute Name Length Bounds

Hi All!

Thanks,
Kathy

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 14 Jun 2003 19:25:17 -0700

Kathy, your suggested specification change would require many
independently developed interoperating implementations to
change their "running code".   Also, unless the limit is very
high, such a limit will invalid existing conformant schema.

Today's TS assumes that all implementations can handle all
valid PDUs they are passed, including handling all allowed
descriptors.  An implementation will recognize and support some
descriptors it will recognize and support, others it won't.
Adding a small size limit won't change that.  It will only
limit LDAP domain of applicability.  (This statement is, I
believe, supported by operational experience in over protocol
which has placed small limits on protocol fields.  For example,
the 20 octet SASL mechanism name limit is makes it unnecessarily
difficult to support arbitrary GSS API mechanisms.)

So, not only is the change not needed, it's going to do
significant harm.   We should not add size limit restrictions
to protocol fields.  They are bad.

I agree that a LDAP "general purpose" client/server
applicability statement, possibly Standard Track, is needed.
I agree that extension guidelines, possibly as a BCP, is
needed.  However, the LDAP "core" technical specification is
neither of these and it shouldn't expanded to include either.

I note, as co-chair, that LDAPBIS is not chartered to produce
either.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Sat, 14 Jun 2003 23:49:15 -0400

I have re-read Kathy's suggestion several times.

I now agree that as worded, it would cause more harm than
good because it places an upper bound on attribute lengths. I
was only concerned with a lower bound to ensure some publicly
known requirement. This would enable users to have some
reasonable degree of assurance that two products claiming
conformance with that requirement should interoperate with
respect to this issue. I do not see that similar (or any)
harm to the use of LDAPv3 would be caused by a lower bound
on attribute type names or object classes.

So I will point back to the suggestion from Rick Huber as
the requirement wording that seems appropriate to me on this
topic.

I maintain my view that this particular issue is of
sufficiently general nature to justify consideration
of adding a requirement to one or more standards track
documents. Some of those could be from this group. That
question I asked in a separate posting to the WG.

I do think there needs to be a bit more discussion about
where such a requirement belongs. It would be nice (and
helpful for Kurt) if folks would say what they think about
where such a requirement belongs and why. That way, if
consensus turns out to be that such a requirement should
be included in one or more of the LDAPBIS deliverables,
we could work on the actual language in the WG.

I think it is unwise to make a blanket statement that
you shouldn't make size limit restrictions to protocol
fields because "they are bad." That's a generalization that
you can't back up with a convincing, general technical argument.
I'm sure there are cases where size limits are bad. I'm equally
certain that there are cases where not having them causes harm.

My assertion is that not having a requirement, somewhere in a
standards track document, for a lower bound on object class
and attribute type names already is causing harm. And we have
a chance to mitigate that harm now. So I would like to see
such a requirement in an appropriate LDAPBIS deliverable.

I've already pointed out that there are multiple
application contexts in which this issue is relevant.

My opinion about where such a requirement belongs is
based on the fact that this is an interoperability issue
that transcends any specific application profile.
Therefore, according to the work LDAPBIS is chartered
to complete, I think it belongs somewhere in one of
the deliverables produced by LDAPBIS.

I realize that others might have different opinions. I can
surmise what a few of those might be to the question of
where such a requirement might belong. I would like to hear
from more folks about their opinions on where such a requirement
belongs and why.

DSI Consulting, Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Kurt D. Zeilenga
Sent: Saturday, June 14, 2003 10:25 PM
To: Kathy Dally
Cc: [email-masked]
Subject: Re: Attribute Name Length Bounds

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Mon, 16 Jun 2003 09:11:07 -0400

> question I asked in a separate posting to the WG.

I will be honest and say that I am not sure where such a requirement 
belongs. Lack of a minimum lower bound does make it difficult for anyone 
to create and publish schema that may be used with all LDAP 
implementations. That seems like a fairly general problem to me.

I also see Jim and Kurt's point about the problems that will arise if 
the LDAPBis group descends down the path of specifying minimum lengths 
for all of the LDAP protocol elements.

-Mark

---

From: Kathy Dally <[email-masked]>
Date: Mon, 16 Jun 2003 17:46:55 -0400

Hi Kurt!

I'm sorry to be so misunderstood.  

The issue that has been raised is not proposing limits on the attribute
values (implying protocol field sizes), only the name (descriptor) of
the attribute or other object.  As far as a small limit, I simply
recommended the number that is already set as a limit in the IANA
considerations for this same issue.  If, in general, descriptor
identifiers need to be more than 48 characters, then the IANA document
needs to be changed.  

Thanks,
Kathy

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 16 Jun 2003 15:21:13 -0700

>I'm sorry to be so misunderstood.  

I think you misunderstand my comments.

>the attribute or other object.

Attribute short names (descriptors) are protocol values (or
tokens) transferred in protocol fields.

>As far as a small limit, I simply

The BCP 64 provides guidelines for registration of LDAP
protocol values, such as short names (descriptors).  Nothing
in BCP 64 disallows a descriptor longer than 48 characters
from being registered.   Nothing in BCP 64 restricts the
length of descriptors which may appear in the protocol.

Also, being just a guideline, it can be revised if found
to be too limiting (or not limiting enough) without having
to change the technical specification.

For example, if the community were to decode that registration
of portions of the name space can be delegated to owners of
domains without involving IANA actions, we'd could publish
a BCP allowing descriptors like
  COM-EXAMPLE-ORGANIZATIONALUNIT-MY-PERSONAL-USER-APPLICATION-ATTRIBUTE
to be used in naming attribute types.

Placing limits on protocol fields would prevent this.

This is what happened with SASL mechanism names.  They
put a 20 character limit into the Technical Specification
instead of just stating a IANA consideration on what
mechanism names were considered too long to register.
Now folks want to use OIDs to name mechanisms (coming from
GSS API) but they cannot without changing the technical
specification.

Kurt

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 16 Jun 2003 16:06:47 -0700 (PDT)

> to be used in naming attribute types.

And let me add that this is not at all a far-fetched notion.  I'm engaged
in making up some conventions for representing attribute-type descriptors
as URNs (for use in XML context), with a result that looks a lot like the
above.  (And why not use urn:oid, you ask?  Don't ask ...)

 - RL "Bob"