Re: Attribute Name Length Bounds

[Kathy Dally <kdally@mitre.org>]

Hi All!

OK with me.

Kathy


Richard V Huber wrote:
> 
> I have no problem with Kathy's text except that I would replace:
> 
>   ... and MUST send object identifier descriptors that are no longer
>   than 48 characters.
> 
> with
> 
>   ... and MUST NOT send object identifier descriptors that are longer
>   than 48 characters.
> 
> This is a wordsmithing comment, not a content comment.
> 
> Rick Huber
> 
> : From owner-ietf-ldapbis@openldap.org Fri Jun 13 14:02:29 2003
> : Return-Path: <owner-ietf-ldapbis@openldap.org>
> : From: Kathy Dally <kdally@mitre.org>
> : To: "Larry S. Bartz" <lbartz@parnelli.indy.cr.irs.gov>
> : CC: capple@dsi-consulting.net, ietf-ldapbis@openldap.org
> : Subject: Re: Attribute Name Length Bounds
> : Sender: owner-ietf-ldapbis@openldap.org
> : Precedence: bulk
> : Comment: ietf-ldapbis mailing list <http://www.OpenLDAP.org/lists/>
> : List-Archive: <http://www.OpenLDAP.org/lists/ietf-ldapbis/>
> : List-Help: <mailto:ietf-ldapbis-request@OpenLDAP.org?body=help>
> : List-Unsubscribe: <mailto:ietf-ldapbis-request@OpenLDAP.org?body=unsubscribe>
> :
> : 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
> :
> :
> : "Larry S. Bartz" wrote:
> : >
> : > Chris Apple wrote, On 06/13/03 10:44:
> : > > 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."
> : >
> : > 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?
> : >
> : >
> :
> : >
> : > Larry
> : >
> : > >
> : > > 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: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 Larry S. Bartz
> : > > Sent: Friday, June 13, 2003 10:48 AM
> : > > To: ietf-ldapbis@OpenLDAP.org
> : > > 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.
> : > >
> :
> :