[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Attribute Name Length Bounds
Actually, I'd like to adjust that response a bit.
I think both the sending and receiving cases need to be MUST
for the requirement to help solve the interoperability problem.
Mixing the strengths of the requirements covering each case
leaves the door open for the same type of interoperability issue
for established use cases (DEN, LDAP mappings of DMTF CIM schema)
of LDAPv3 involving attribute names approaching the bound specified.
Chris Apple - Principal Architect
DSI Consulting, Inc.
mailto:capple@dsi-consulting.net
http://www.dsi-consulting.com
-----Original Message-----
From: Chris Apple [mailto:capple@dsi-consulting.net]
Sent: Friday, June 13, 2003 2:49 PM
To: 'Kathy Dally'; 'Larry S. Bartz'
Cc: 'ietf-ldapbis@OpenLDAP.org'
Subject: RE: Attribute Name Length Bounds
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.
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 Kathy Dally
Sent: Friday, June 13, 2003 2:00 PM
To: Larry S. Bartz
Cc: capple@dsi-consulting.net; ietf-ldapbis@OpenLDAP.org
Subject: Re: Attribute Name Length Bounds
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.
> >