Subject: RE: Attribute Name Length Bounds

From: [email-masked] (Richard V Huber)
Date: Fri, 13 Jun 2003 13:24:51 -0400 (EDT)

In line with Larry Bartz' email mentioning RFC3383, how about:

  To promote interoperability, server implementors SHOULD allow at
  least 48 characters for attribute names and schema designers SHOULD
  use attribute names which are no longer than 48 characters.

If we allow 48 character names to be registered, the standard ought to
support them.

I don't see much use for an upper bound.  People who are worried about
interoperability always have to live within the lower bound in any case.

Rick Huber

: From [email-masked] Fri Jun 13 11:53:42 2003
: Return-Path: <[email-masked]>
: From: "Chris Apple" <[email-masked]>
: To: "'Larry S. Bartz'" <[email-masked]>,
:         <[email-masked]>
: Subject: RE: Attribute Name Length Bounds
: Sender: [email-masked]
: Precedence: bulk
: Comment: ietf-ldapbis mailing list <http://www.OpenLDAP.org/lists/>
: List-Archive: <http://www.OpenLDAP.org/lists/ietf-ldapbis/>
: List-Help: <mailto:[email-masked]?body=help>
: List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
: 
: 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.
: 
: 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 Larry S. Bartz
: Sent: Friday, June 13, 2003 10:48 AM
: To: [email-masked]
: Subject: Re: Attribute Name Length Bounds
: 
: 
: Mark C Smith wrote, On 06/13/03 08:26:
: > Jim Sermersheim wrote:
: > 
: >> 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.
: > 
: > 
: > 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
: 
: 
: 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 13:39:24 -0400

I'm in favor of the clarification about what schema designers should do.

I also like Larry's broader language for the types of names to which this
lower bound applies.

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 Richard V Huber
Sent: Friday, June 13, 2003 1:25 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: RE: Attribute Name Length Bounds

Rick Huber

: List-Unsubscribe:
<mailto:[email-masked]?body=unsubscribe>
: You can create a shorter attribute name and then use the intended
attribute
: >> attribute names. Any limitiation in a specific implementation is
imposed

---

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

>  use attribute names which are no longer than 48 characters.

Let's look at each imperative separately.  First the latter:
  Schema designers SHOULD use attribute names which are no
  longer than 48 characters.

I think that BCP64, with the additions agreed upon in [Models],
basically covers this.  That is, BCP64bis will say that all
descriptors (excepting those in private name space) SHOULD be
registered and all descriptors in RFCs MUST be registered
in addition to say that descriptors longer than 48 may be
viewed as too long to register.

While not precisely a requirement upon all schema (because
it doesn't cover private name space elements), it certainly is
significant encouragement to schema designers to avoid
descriptors longer than 48.

If a more precise requirement is desired, I suggest this be
stated in a future "guidelines for schema developers" BCP
along with the many other requirements that likely should be
stated to schema developers.

Now the former:
  Server implementors SHOULD allow at least 48 characters for attribute names

Stating this in the LDAP TS is problematic as there is no
requirement (and rightly so) for server implementation to
support open-ended sets of attribute types.  While certainly
servers limit the sets of attribute types they support, they do
by many means.  Name length is just one factor.  From a protocol
interoperability stand point, this is not problem.

Basically, vendors have chosen to limit the suitability to
various markets.  That's their choice.

Now, what folks want is for vendors who claim to support
open-ended sets of attribute types to implement some minimum
set of requirements.  Or to say it another way, folks want
an applicability statement for a restricted domain of
applicability for which servers can claim to support.  That
domain being "servers which support open-ended sets of
attribute types" or maybe "general-purpose servers".

Note here that as no server is required to be a "general-purpose
server", we are talking about requirements for a restricted
domain of applicability.

As we've discussed in the past, those requirements are better
stating in a separate document which offers such an
applicability statement.

It's my view what is needed is two new documents:
        "Guidelines for LDAP schema developers"
        "Applicability Statement for general-purpose LDAP servers"

There is a fair amount of prior work in each of these areas.
Bruce long ago wrote an I-D on the former, and much of that
found its way in to my "Considerations for LDAP Extensions"
I-D (which covers schema as well as other kinds of extensions).
Also, the Open Group DIF is writing what are, in effect,
applicability statements for their directory certification
programs.

I think its best for these works to continue on an individual
basis.  LDAPBIS needs to remain (at least for now) focused on
delivering the "core" (technical) specification.

Kurt

---

From: Ryan Moats <[email-masked]>
Date: Mon, 16 Jun 2003 15:11:43 -0500

Kurt-

It is *NOT* clear to me whether you are speaking as co-chair or
something else or both.  Can you please note (going forward)
which comments are being made with which hat on?

Thanks,
Ryan

On Mon, Jun 16, 2003 at 12:50:12PM -0700, Kurt D. Zeilenga wrote:
| At 10:24 AM 6/13/2003, Richard V Huber wrote:
| >In line with Larry Bartz' email mentioning RFC3383, how about:
| >
| >  To promote interoperability, server implementors SHOULD allow at
| >  least 48 characters for attribute names and schema designers SHOULD
| >  use attribute names which are no longer than 48 characters.
| 
| Let's look at each imperative separately.  First the latter:
|   Schema designers SHOULD use attribute names which are no
|   longer than 48 characters.
| 
| I think that BCP64, with the additions agreed upon in [Models],
| basically covers this.  That is, BCP64bis will say that all
| descriptors (excepting those in private name space) SHOULD be
| registered and all descriptors in RFCs MUST be registered
| in addition to say that descriptors longer than 48 may be
| viewed as too long to register.
| 
| While not precisely a requirement upon all schema (because
| it doesn't cover private name space elements), it certainly is
| significant encouragement to schema designers to avoid
| descriptors longer than 48.
| 
| If a more precise requirement is desired, I suggest this be
| stated in a future "guidelines for schema developers" BCP
| along with the many other requirements that likely should be
| stated to schema developers.
| 
| Now the former:
|   Server implementors SHOULD allow at least 48 characters for attribute names
| 
| Stating this in the LDAP TS is problematic as there is no
| requirement (and rightly so) for server implementation to
| support open-ended sets of attribute types.  While certainly
| servers limit the sets of attribute types they support, they do
| by many means.  Name length is just one factor.  From a protocol
| interoperability stand point, this is not problem.
| 
| Basically, vendors have chosen to limit the suitability to
| various markets.  That's their choice.
| 
| Now, what folks want is for vendors who claim to support
| open-ended sets of attribute types to implement some minimum
| set of requirements.  Or to say it another way, folks want
| an applicability statement for a restricted domain of
| applicability for which servers can claim to support.  That
| domain being "servers which support open-ended sets of
| attribute types" or maybe "general-purpose servers".
| 
| Note here that as no server is required to be a "general-purpose
| server", we are talking about requirements for a restricted
| domain of applicability.
| 
| As we've discussed in the past, those requirements are better
| stating in a separate document which offers such an
| applicability statement.
| 
| It's my view what is needed is two new documents:
|         "Guidelines for LDAP schema developers"
|         "Applicability Statement for general-purpose LDAP servers"
| 
| There is a fair amount of prior work in each of these areas.
| Bruce long ago wrote an I-D on the former, and much of that
| found its way in to my "Considerations for LDAP Extensions"
| I-D (which covers schema as well as other kinds of extensions).
| Also, the Open Group DIF is writing what are, in effect,
| applicability statements for their directory certification
| programs.
| 
| I think its best for these works to continue on an individual
| basis.  LDAPBIS needs to remain (at least for now) focused on
| delivering the "core" (technical) specification.
| 
| Kurt
| 
|

---

From: Ryan Moats <[email-masked]>
Date: Mon, 16 Jun 2003 15:28:23 -0500

On Mon, Jun 16, 2003 at 03:11:43PM -0500, Ryan Moats wrote:
| Kurt-
| 
| It is *NOT* clear to me whether you are speaking as co-chair or
| something else or both.  Can you please note (going forward)
| which comments are being made with which hat on?
| 
| Thanks,
| Ryan

ugh... that should be a *not* not a *NOT*.  stupid caps lock...

Ryan

| On Mon, Jun 16, 2003 at 12:50:12PM -0700, Kurt D. Zeilenga wrote:
| | At 10:24 AM 6/13/2003, Richard V Huber wrote:
| | >In line with Larry Bartz' email mentioning RFC3383, how about:
| | >
| | >  To promote interoperability, server implementors SHOULD allow at
| | >  least 48 characters for attribute names and schema designers SHOULD
| | >  use attribute names which are no longer than 48 characters.
| | 
| | Let's look at each imperative separately.  First the latter:
| |   Schema designers SHOULD use attribute names which are no
| |   longer than 48 characters.
| | 
| | I think that BCP64, with the additions agreed upon in [Models],
| | basically covers this.  That is, BCP64bis will say that all
| | descriptors (excepting those in private name space) SHOULD be
| | registered and all descriptors in RFCs MUST be registered
| | in addition to say that descriptors longer than 48 may be
| | viewed as too long to register.
| | 
| | While not precisely a requirement upon all schema (because
| | it doesn't cover private name space elements), it certainly is
| | significant encouragement to schema designers to avoid
| | descriptors longer than 48.
| | 
| | If a more precise requirement is desired, I suggest this be
| | stated in a future "guidelines for schema developers" BCP
| | along with the many other requirements that likely should be
| | stated to schema developers.
| | 
| | Now the former:
| |   Server implementors SHOULD allow at least 48 characters for attribute names
| | 
| | Stating this in the LDAP TS is problematic as there is no
| | requirement (and rightly so) for server implementation to
| | support open-ended sets of attribute types.  While certainly
| | servers limit the sets of attribute types they support, they do
| | by many means.  Name length is just one factor.  From a protocol
| | interoperability stand point, this is not problem.
| | 
| | Basically, vendors have chosen to limit the suitability to
| | various markets.  That's their choice.
| | 
| | Now, what folks want is for vendors who claim to support
| | open-ended sets of attribute types to implement some minimum
| | set of requirements.  Or to say it another way, folks want
| | an applicability statement for a restricted domain of
| | applicability for which servers can claim to support.  That
| | domain being "servers which support open-ended sets of
| | attribute types" or maybe "general-purpose servers".
| | 
| | Note here that as no server is required to be a "general-purpose
| | server", we are talking about requirements for a restricted
| | domain of applicability.
| | 
| | As we've discussed in the past, those requirements are better
| | stating in a separate document which offers such an
| | applicability statement.
| | 
| | It's my view what is needed is two new documents:
| |         "Guidelines for LDAP schema developers"
| |         "Applicability Statement for general-purpose LDAP servers"
| | 
| | There is a fair amount of prior work in each of these areas.
| | Bruce long ago wrote an I-D on the former, and much of that
| | found its way in to my "Considerations for LDAP Extensions"
| | I-D (which covers schema as well as other kinds of extensions).
| | Also, the Open Group DIF is writing what are, in effect,
| | applicability statements for their directory certification
| | programs.
| | 
| | I think its best for these works to continue on an individual
| | basis.  LDAPBIS needs to remain (at least for now) focused on
| | delivering the "core" (technical) specification.
| | 
| | Kurt
| | 
| |

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 16 Jun 2003 14:31:00 -0700

>which comments are being made with which hat on?

It's my general practice (though I likely have slipped in the
past and likely will again in the future) to mark each statement
coming from the chair in some way.  I try to sign major statements
from the chair with "LDAPBIS co-chair" but do occasionally inject
comments from the chair with "as co-chair... ", or equivalent.  Also,
I occasionally mark individual comments using "Personally, ..."
when I think the comment might be misconstrued as coming from the
chair, but comments I make as an individual are generally not
qualified.  Hence, if its not explicitly labeled as coming from
the chair, I likely didn't intend for it to be treated as coming
from the chair.  If I didn't mark something as coming from the
chair when it should have been, I won't fault you or others for
my error.  I'll just post a clarification.

I intend to continue with this practice and will try my best not
to slip too much.

In reviewing this thread, I believe no clarifications are needed.
That is, I believe I've explicitly marked the one comment I made
from the chair (with "as co-chair").  All my other comments were
made as a WG member.

With apologies for past and future slips, Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 17 Jun 2003 14:35:45 +1000

Kurt,

>         "Applicability Statement for general-purpose LDAP servers"

Or an "LDAP Implementation Guide". Either way, I agree that size limits
and such don't belong in the LDAPbis core specifications. It's pretty
clear that the core documents don't impose limits or even suggest that
there may be limits. The situation we have is that some implementors
have cut corners for their own convenience and been caught out.

I think the main message should always be "don't impose limits". Whatever
limits we might impose now are likely to eventually prove inadequate
and need revising. If we are going to suggest limits of some sort then
it's better if that is in an informational "guidelines" document than
in the technical specification.

Regards,
Steven