Subject: RE: Attribute Name Length Bounds

From: John McMeeking <[email-masked]>
Date: Fri, 13 Jun 2003 12:55:24 -0500

Should the "schema designers SHOULD" be accompanied by something like
"Standards track schemas MUST use ..."?  Or does that go better with IANA
name registration?

Also, I assume this entire discussion applies to objectclass names.

John  McMeeking

                      [email-masked]                                                                                    
                      (Richard V Huber)           To:       [email-masked], [email-masked],            
                      Sent by:                     [email-masked]                                           
                      owner-ietf-ldapbis@O        cc:                                                                        
                      penLDAP.org                 Subject:  RE: Attribute Name Length Bounds                                 

                      06/13/2003 12:24 PM                                                                                    

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 14:57:51 -0400

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:[email-masked]

http://www.dsi-consulting.com

-----Original Message-----
From: Chris Apple [mailto:[email-masked]] 
Sent: Friday, June 13, 2003 2:49 PM
To: 'Kathy Dally'; 'Larry S. Bartz'
Cc: [email-masked]'
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:[email-masked]

http://www.dsi-consulting.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Kathy Dally
Sent: Friday, June 13, 2003 2:00 PM
To: Larry S. Bartz
Cc: [email-masked]; [email-masked]
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:[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.
> >

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 13 Jun 2003 19:30:58 -0600

Ah yes...
And how many controls in a SEQUENCE OF Control?
And how many attribute values in a SET of AttributeValue?
And how many LDAPURLs in a Referral or SearchResultReference?
And how many modifications in a ModifyRequest?

I guess the answer my friend, is blowin' in the wind.

>>> "Kurt D. Zeilenga" <[email-masked]> 6/13/03 6:58:49 PM >>>
I've added some more questions below to your list.

Basically, the answer to all of these questions is "it depends".
In particular, it depends on the circumstances of the use of the
protocol.  As LDAP is intended to have a general domain of
applicability, it's best to leave such answers to applicability
statements covering particular circumstances.  That is, we should
leave the answering of these questions to future applicability
statements of restricted domain of applicability (such as use in
PKI, use in white pages, use in ...., use for a "general purpose").

Kurt

At 03:43 PM 6/13/2003, Jim Sermersheim wrote:
>I'm still a little fuzzy on the scope of this discussion.
>
>The ASN.1 for attribute names is an unbounded OCTET STRING. 
>
>This discussion seems to be saying "even though the protocol says the
>size is unlimited (well, limited to a ber length), we want to be more
>explicit and require protocols peers to handle some minimum size".
>
>What else does this discussion apply to?

How many RDNs in a DN must implementations support?
How many AVAs in a RDN must implementations support?
How many options in an attribute description must implementations
  support?
How many descriptions in an attribute description list must
  implementations support?
How many broad of a filter specification must implementations support?
How many deep of a filter specification must implementations support?
How many any substrings in a substrings assertion must implementations
  support?
..

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 16 Jun 2003 22:21:36 -0600

Yes, (sequence of octets = octet string). Not following asn.1
terminology, just trying to avoid typing more words than I had to.

Jim

>>> "Chris Apple" <[email-masked]> 6/16/03 10:08:51 PM >>>
I found that confusing as well.

Peter: could you please clarify or elaborate?

Jim: I agree with your generalized problem statement.
I'm guessing that the sequence of octets in an
attribute type name or object class name is how
your covering the specific problem I found
under this general statement. Is that accurate?

DSI Consulting, Inc.

-----Original Message-----
From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Jim Sermersheim
Sent: Monday, June 16, 2003 11:52 PM
To: [email-masked] 
Subject: RE: Attribute Name Length Bounds

Did you mean to say the generlized problem *is* related to the length?

As I see it, the generalized problem is that there are sequences
defined in the LDAP protocol and models, and because no requirements
to
support a minimum lower or maximum upper number of elements in some of
them have and will cause certain applications to fail.

Jim

>>> Peter Bachman <[email-masked]> 6/16/03 9:12:40 PM >>>

The generalized problem then is not related to the length, i take it,
since
there's no requirement that a specific length, can or cannot represent
the
information that's captured in schema, even if it causes problems of
interoperability.

-pb

On Mon, 16 Jun 2003 09:41:46 -0600
"Jim Sermersheim" <[email-masked]> wrote:

>>What is beginning to concern me is that your words imply that
>>it is inappropriate to address known interoperability issues
>>in preparation for moving to Draft Standard. 
>
>Well, I never said that, and it's not my intent at all.
>
>I agreed that this is a problem. I'm not suggesting that it be
ignored.
>I'm also not suggesting that we get all extreme and put mandatory
>minimums on all sequences in the protocol/data model. 
>
>My intent is to ask that we view the general problem, and not just
one
>aspect that happens to have reared its head recently.
>
>Jim
>
>
>>>> "Chris Apple" <[email-masked]> 6/14/03 4:00:29 PM >>>
>I would be fine with it if the scope was attribute type names
>and object class names.
>
>What is beginning to concern me is that your words imply that
>it is inappropriate to address known interoperability issues
>in preparation for moving to Draft Standard. It's true that it
>has become a known problem because of recent work I've done.
>The timing doesn't diminish the importance of discussing it
>in this forum; nor does it diminish the negative impact it will
>have on deploying services using the protocol in the field if
>there isn't some requirement addressing this particular known
>issue.
>
>I'm sure it's a good idea to look at the problem in a general
>way. I'm also sure that most users would appreciate
>tempering pure technical merit with pragmatic deployment
>concerns along the way.
>
>The idea of addressing this particular issue with a requirement
>seems to have some supporters and some folks who don't think its
>a good idea. But there hasn't been a lot of discussion about
>which LDAPBIS deliverable this might apply to.
>
>Notice that I actually stated that I didn't know where to even
>suggest its inclusion at the start of this thread. Nor do I at
>this time.
>
>That is perhaps a question that needs to be asked and answered
>explicitly. So consider it asked. Where do folks think such a
>requirement belongs? In one of the LDAPBIS deliverables? Or
>somewhere else (and where if that's the case)?
>
>[mailto:[email-masked]] On Behalf Of Jim Sermersheim
>Sent: Saturday, June 14, 2003 2:16 PM
>>I wouldn't take it further than that because I don't have real world
>>examples that justify doing so.
>
>This is exactly my concern. It seems coincidental that you are seeing
>this problem, we are edititng the specification, so you see a chance
>to
>fix this problem. If you hadn't seen this problem at this particular
>time, and the spec got progressed without this change, then I suspect
>the problem would be addressed in some other way (one of those talked
>about earlier in the thread).
>
>Given this concern, I decided to have a look at some of the other
>potential 'problems' that are the same as this one.
>
>If, instead of this problem, you found that some servers limited DNs
>to
>32 characters, we might be having that conversation instead of this
>one.
>I don't see the difference between schema lenghts and some of the
>other
>sequences listed in this thread. If you want to draw the line at
those
>things which have IANA considerations, then we throw out sizes on
>other
>schema elements, and add in sizes on other things (like SASL
>mechanism).
>What's happenning here is a jump over to the IANA reasoning, then a
>hop
>over to a "similar elements" reasoning.
>
>To paraphase, my concern is that we're jumping on a problem just
>because someone happened to experience it, without looking at it in a
>general way. 
>
>If we add this change, it sets a precedence for a class of
>instructions
>that was never part of the original spec. We shouldn't do this in
such
>an isolated way. That only makes future readers scratch their heads
>wondering at the inconsistency.
>
>I don't understand why this can't be specified in an application
>profile document. I would say that there's a class of application
that
>must add to (extend) the standard LDAP schema. For LDAP servers to
>service this class of applications, then they should handle
reasonable
>schema name lengths. I don't think the LDAP spec even says that an
>LDAP
>server needs to allow its schema to be extended, only that it must
>support certain standard schema.
>
>Jim
>
>>>> "Chris Apple" <[email-masked]> 6/13/03 9:16:48 PM >>>
>My intended scope was names for schema elements such as
>attribute types, object class identifiers, attribute
>syntaxes, matching rules, and anything else that might
>be mapped to an OID with an associated, registered name.
>
>Given that there are IANA considerations for the registration
>of at least some of those types of schema elements, I don't
>think I'm proposing anything that is outrageous or unreasonable.
>
>I absolutely agree that most of the examples you gave should be
>handled in the context of profiling LDAPv3 DIT structure,
>Operations, Service Model, etc., for specific applications.
>
>I'm of the opinion that this particular minimum size requirement
>is of more general use than a specific application profile. I've
>already given two different examples where this is an issue.
>I'll repeat them here along with a third:
>
>	- DEN
>	- LDAPv3 mappings of the DMTF CIM
>	- The Open Group's Mobility and Directory (MaD) Schema
>	  (this will be publicly presented at the Burton Group's
>	   Catalyst meeting in July 2003 - but basically its an
>	   information model for directory-enabled mobility
>	   management)
>
>Those are all different application contexts. Each has a need
>for attribute type names that are longer than the maximum
>attribute length supported by some LDAPv3-compliant implementations.
>
>Thus it is generally valuable to have a minimum length requirement
>for at least attribute type names and object class identifiers. By
>extension it also seems generally valuable to have the same sort of
>minimum supported length for names of matching rules and attribute
>syntaxes.
>
>I wouldn't take it further than that because I don't have real world
>examples that justify doing so.
>
>However, to accommodate the 3 schema specifications above in
>a general way, I do believe its justified. Specifying such
>a minimum schema element name length requirement would solve an
>interoperability problem related to using the protocol in the real
>world in at least three different and very significant application
>contexts. I think that's very much in line with the intent of
>progressing to Draft Standard. If we were to waive our hands about
>this and say, it means that we are interoperable if we just say
>we don't understand something that's been sent to us, we haven't
>actually helped the users with a relatively costly interoperability
>problem.
>
>I don't think hand waving makes for good standards when
>there's a need such as this that crosses multiple application
>contexts. Especially when such a requirement can scoped so
>that it doesn't cause the kind of "here a limit, there a limit,
>everywhere a limit" rat hole that some of the most recent postings
>implied might happen.
>
>[mailto:[email-masked]] On Behalf Of Jim Sermersheim
>Sent: Friday, June 13, 2003 6:43 PM
>- LDAPDN (how long of a DN am I required to handle?)
>- RelativeLDAPDN 
>- AttributeValue/AssertionValue (I note that the current len
>descriptor
>on attributes is a 'suggested minimum')
>- MatchingRuleId
>- LDAPResult.diagnosticMessage
>- LDAPURL (I suppose enough for a minimal scheme and delimiters is
>implied)
>- SASL mechanism (implied 1 to 20)
>- SASL credentials
>- LDAPOID
>- control/extendedValue
>- simple password
>
>AFAIK, today these all have a max-ber-len max. and no mandatory
>minimum
>is explicitly required to be supported.
>
>Jim
>
>

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 20 Jun 2003 13:59:36 +1000

This is a silly suggestiion, of course every octet in a PDU is significant. If this was an ellipses for "every octet of every attribute description in a PDU is significanr" then it is inappropriate - it is not an ASN.1 issue, it is an application issue.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Friday, 20 June 2003 13:02
To: Howard Chu
Cc: [email-masked]
Subject: RE: Attribute Name Length Bounds

At 08:29 PM 6/17/2003, Howard Chu wrote:
>> The point is that the possibility of interpreting
>> the specs in this way already set us up for deployment
>> issues related to several published schema with attribute
>> names on the longer side of what might have been considered
>> typical a few years ago.
>
>If the server rejects overly-long names with an error message, fine, but your
>message implied that it silently ignored the characters comprising the excess
>length in the name. If it seems that the spec is ambiguous about the
>significance of characters in a short name, perhaps it would be sufficient to
>state in the the spec "all of the characters in an attribute name are
>significant.

One could argue that the TS should be clarified to say:
  All bits of very octet of the PDU are significant unless stated otherwise.

However, I think basically already says this already in X.680/X.690.  But,
I don't see much harm in restating this in [Protocol] (even though I think
it a bit redundant and quite obvious).

I, however, think we should avoid per field statements (except for the
otherwise cases).

>If an attribute name is presented that exceeds a server's
>implementation limits, the server MUST fail the request with an error code."

That would be, in general, a bad thing.  Servers should treat attribute type
names they don't recognize as unrecognized attribute types and many of these
cases don't result in an error being returned.

Kurt

---

From: [email-masked] (Richard V Huber)
Date: Tue, 24 Jun 2003 16:04:16 -0400 (EDT)

As noted in Chris' email that started this discussion, it seems there
are implementations that do NOT consider every octet of every attribute
description to be significant.  So there is evidence that the current
documents were not interpreted the same way by all implementors and
there are interoperability problems if we say nothing.

So I think it should be clarified in the new documents.

Rick Huber

: From [email-masked] Tue Jun 24 15:09:42 2003
: Return-Path: <[email-masked]>
: From: "Chris Apple" <[email-masked]>
: To: "'Jim Sermersheim'" <[email-masked]>, <[email-masked]>
: Subject: RE: Attribute Name Length Bounds
: Sender: [email-masked]
: 
: I think that's a consensus judgment call that
: the Co-Chairs need to make based on the discussion
: so far...
: 
: 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 Jim Sermersheim
: Sent: Monday, June 23, 2003 2:17 PM
: To: [email-masked]
: Subject: RE: Attribute Name Length Bounds
: 
: 
: Can we answer the question:
: 
: Does any work need to happen to the LDAP TS to address this particular
: issue? 
: 
: Any suggested changes I've heard so far have worried me for one reason
: or another.
: 
: Jim
: 
: >>> "Ramsay, Ron" <[email-masked]> 6/19/03 9:59:36 PM >>>
: This is a silly suggestiion, of course every octet in a PDU is
: significant. If this was an ellipses for "every octet of every attribute
: description in a PDU is significanr" then it is inappropriate - it is
: not an ASN.1 issue, it is an application issue.
: 
: -----Original Message-----
: From: Kurt D. Zeilenga [mailto:[email-masked]] 
: Sent: Friday, 20 June 2003 13:02
: To: Howard Chu
: Cc: [email-masked] 
: Subject: RE: Attribute Name Length Bounds
: 
: 
: At 08:29 PM 6/17/2003, Howard Chu wrote:
: >> The point is that the possibility of interpreting
: >> the specs in this way already set us up for deployment
: >> issues related to several published schema with attribute
: >> names on the longer side of what might have been considered
: >> typical a few years ago.
: >
: >If the server rejects overly-long names with an error message, fine,
: but your
: >message implied that it silently ignored the characters comprising the
: excess
: >length in the name. If it seems that the spec is ambiguous about the
: >significance of characters in a short name, perhaps it would be
: sufficient to
: >state in the the spec "all of the characters in an attribute name are
: >significant.
: 
: One could argue that the TS should be clarified to say:
:   All bits of very octet of the PDU are significant unless stated
: otherwise.
: 
: However, I think basically already says this already in X.680/X.690. 
: But,
: I don't see much harm in restating this in [Protocol] (even though I
: think
: it a bit redundant and quite obvious).
: 
: I, however, think we should avoid per field statements (except for the
: otherwise cases).
: 
: >If an attribute name is presented that exceeds a server's
: >implementation limits, the server MUST fail the request with an error
: code."
: 
: That would be, in general, a bad thing.  Servers should treat attribute
: type
: names they don't recognize as unrecognized attribute types and many of
: these
: cases don't result in an error being returned.
: 
: Kurt
: 
: 
: 
: 
: