[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Attribute Name Length Bounds
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.
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 Kurt D. Zeilenga
Sent: Saturday, June 14, 2003 10:25 PM
To: Kathy Dally
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Attribute Name Length Bounds
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.
>> >