[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Attribute Name Length Bounds
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
"Kurt D. Zeilenga" wrote:
>
> 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
>
> At 10:59 AM 6/13/2003, Kathy Dally wrote:
> >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.
> >> >