Subject: Get rid of "suggested minimum upper bound"

From: Michael Ströder <[email-masked]>
Date: Fri, 08 Mar 2002 18:14:58 +0100

HI!

Inspired by some discussion on [email-masked] I will try to raise the 
discussion about the "suggested minimum upper bound" here.

Mainly because I believe any upper bound which is not mandantory is useless 
for implementations and should be removed from the standard.

If anyone considers some kind of upper bounds to contain valuable 
information for e.g. secure an implementation against DoS attacks we should 
discuss how to provide a mechanism for specifying a mandantory upper bound 
(hard limit) in a separate discussion thread.

Kurt D. Zeilenga wrote:
 > At 03:34 PM 2002-03-07, Jim Willeke wrote:
 >
 >>
 >>Now, exactly what is a "suggested minimum upper bound" ?
 >>
 >
 > It suggests that implementations support at least that size.
 > Servers may support larger sizes (many servers don't place
 > arbitrary restrictions on size of values).
  > [..]
 > There may be a hard upper bound, but this doesn't specify that
 > that upper bound is.  It suggests servers should allow at least
 > this length.

So there's no real value specifying a minimum upper bound. No implementation
can rely on it. Neither a LDAP client nor a server.

 > The other section you note is known to be inconsistent.  4.3.2
 > is generally considered (IMO) to reflect the intended semantics.
 > This will be clarified in the next revision of the technical
 > specification.

LDAPbis should consider to remove that misleading minimum upper bound from
the standards document because it's useless and causes nothing than confusion.

 >>Should a server allow more?
 >
 > It may.

In practice it MUST because an implementation cannot derive any valuable 
information from suggested minimum upper bound.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 10 Mar 2002 22:13:03 -0800

I don't think we can just replace noidlen with numericoid
in the AttributeTypeDescription ABNF.  That would likely cause
interoperability problems.

I agree clarification is needed.  Minimally, the words
"maximum length" in 4.2 needs to be replaced with
"suggested minimum upper bound".

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Mon, 11 Mar 2002 17:11:52 +0100

> "suggested minimum upper bound".

Maybe what we should clarify first whether there's any known implementation 
which believes to do anything useful with it.

Comments by server and client implementors would be appreciated.

Ciao, Michael.

---

From: [email-masked] (Mark C Smith)
Date: Mon, 11 Mar 2002 11:32:06 -0500

Michael Ströder wrote:

> Maybe what we should clarify first whether there's any known 
> implementation which believes to do anything useful with it.
> 

The Netscape Directory Server ignores the {length}. It does allow a 
length to be present in the schema, so some clients may be using it. I 
do not personally know of any clients that do so though.

-- 
Mark Smith
AOL Strategic Business Solutions
My words are my own, not my employer's.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 11 Mar 2002 08:38:22 -0800

At 08:11 AM 2002-03-11, Michael Ströder wrote:
>Maybe what we should clarify first whether there's any known implementation which believes to do anything useful with it.

Lots of defined schema, using this ABNF, contains suggested
minimum upper bounds.  A large number of client and server
implementations support updating this schema via the protocol.
Changing the ABNF would require all these implementations
refuse to accept this defined schema.  That would be bad thing.

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Mon, 11 Mar 2002 20:23:37 +0100

Kurt D. Zeilenga wrote:
>>Maybe what we should clarify first whether there's any
 >>known implementation which believes to do anything useful with it.
> 

Kurt, you are already one step further with thinking about how to tweak the 
standard documents.

Basically I asked for feedback of implementors. If anyone relies on the 
"suggested minimum upper bound" (formerly known as "maximum length" ;-) and 
how implementations are interpreting the meaning of it.

Afterwards (or parallel) we can discuss the ABNF off course.

Ciao, Michael.

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 12 Mar 2002 15:37:20 +1100

Michael,

> how implementations are interpreting the meaning of it.

The Adacel implementation parses the length specifier but ignores
its value.

Regards,
Steven

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 12 Mar 2002 15:43:36 +0100

Sun Directory Services 3.1 used to recognise the "maximum length" and verified
that the attribute value wasn't bigger than that length.

I speak in the past as Sun DS 3.1 is still used by customers but we're not
doing further developments.

Ludovic.

--
Ludovic Poitou
Sun Microsystems Inc.
iPlanet E-Commerce Solutions - Directory Group - Grenoble - France

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 13 Mar 2002 09:47:43 -0800

At 11:23 AM 2002-03-11, Michael Ströder wrote:
>Basically I asked for feedback of implementors. If anyone relies on the "suggested minimum upper bound" (formerly known as "maximum length" ;-) and how implementations are interpreting the meaning of it.

I believe we have multiple independently developed interoperable
implementations supporting the "suggested minimum upper bound" as
detailed in RFC 2252, 4.3.2.  I note that server which enforce the
"suggested minimum upper bound" as their upper bound are compliant
with this section.  As the section places no specific semantics
which clients are to implement, I believe it is sufficient that be
(which I believe there are) multiple client implementations which
recognize and generate values per the grammar.

I think the specification just needs to be more clear in that
this is not a "maximum length".  I don't think it would be
appropriate to alter the ABNF nor to change the meaning
from that described in RFC 2252, 4.3.2.

Kurt