Subject: Re: IETF ldapbis WG Last Call:draft-ietf-ldapbis-user-schema-05.txt

From: "Mark Hinckley" <[email-masked]>
Date: Fri, 16 May 2003 13:45:42 -0600

I have reviewed the user-schema draft, and have the following comments:

2.5 * upper bound on 'description' attribute is 1024.  Any chance of relaxing that value?  I know X.520 specifies this limit, so it probably isn't too likely, but it would be nice.  (I know we can't really change this, but I just had to ask anyway.)

2.18 * 'name' upper bound is shown as 32768.  The 93 version of the X.520 document I have access to lists ub-name value twice, with values of 64 and 32768.  But the 2001 version of the doc only has the value listed as 64.   This does seem overly restrictive to me, so is this intended to be the 32K value instead of 64?

2.16 * 'l' and 2.33 - 'st' * both inherit from 'name' with its limit.  Most of the other items that inherit from 'name' either have the same upper bound defined in X.520, or don't even have their own upper bound definition, just inheriting the value from 'name'.  However, both 'l' and 'st' have explicit upper bounds of 128 given in X.520 (Annex C).  Is there any way to specify that in the definition given here?

3.2 - "C" - If we are deprecating the 'searchGuide' attribute, why is it still part of the Country definition (and enhanceSearchGuide is not?)

3.4 * "domain" * ditto for 'teletexTerminalIdentifier' being deprecated.

3.8 * "organization" * since it has the identical set of  attributes in the MAY list as "organizationalUnit", and the list of attributes on "organizationalUnit" appear to be listed in alphabetical order, why is the same list of attributes given in apparently random order for "organization"?

Generally speaking, is there some reason not to list the attributes of a class definition in alphabetical order?

>>> "Kurt D. Zeilenga" <[email-masked]> 05/16/03 12:50PM >>>
Please note that the last call period will close soon....  Also,
if you have reviewed the latest revision of this I-D and find
no problems, you should still comment!  Thanks, Kurt

At 05:12 PM 5/5/2003, Kurt D. Zeilenga wrote:
>This message initiates a LDAPbis Working Group Last Call on the
>document:
>
>          LDAP: User Schema
>          <draft-ietf-ldapbis-user-schema-05.txt>
>
>The purpose of this WG Last Call it to ensure that the Working Group
>has achieved consensus that the document is suitable for publication
>as an IETF Draft Standard.
>
>Please review the document for both technical and editorial problems.
>Technical issues should be discussed on this list.  Editorial issues
>may be sent to the document editor.
>
>The Last Call period will end on Wednesday, May 21, 2003.
>
>Upon completion of the last call, the WG chair(s) will take action
>based upon the consensus of the WG.  Possible actions include:
>
>  1) recommending to the IETF Application Area Directors that the
>     document, after possible editorial or other minor changes, be
>     considered by the IESG for publication as a Draft Standard
>     (which generally involves an IETF-wide Last Call); or
>
>  2) requiring that outstanding issues be adequately addressed prior
>     to further action (including, possibly, another Last Call).
>
>Remember that it is our responsibility as Working Group members to
>ensure the quality of our documents and of the Internet Standards
>process.  So, please read and comment!
>
> - Kurt Zeilenga
>   LDAPbis co-chair

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 19 May 2003 14:19:27 +1000

Mark,

Mark Hinckley wrote:
> 2.5 * upper bound on 'description' attribute is 1024.  Any 
> chance of relaxing that value?

It is already relaxed. The meaning LDAP applies to the curly braces
following a syntax OID is that a server should allow values of at
least that number of characters. Values with more characters are
permitted.

> I know X.520 specifies this 
> limit, so it probably isn't too likely, but it would be nice.

In X.520 the limit is an upper limit on size, but the limits X.520
imposes are, in any case, non-normative. An implementation is free to
impose whatever upper limits it wants, either higher or lower that
the ones suggested by X.520.

My recommendation is that the user schema draft simply remove all
the upper bounds to avoid confusion. They are not hard limits in
either LDAP or X.500.

>  (I know we can't really change this, but I just had to ask anyway.)

We can change it, so it was worth asking.

Regards,
Steven

> 
> 2.18 * 'name' upper bound is shown as 32768.  The 93 version 
> of the X.520 document I have access to lists ub-name value 
> twice, with values of 64 and 32768.  But the 2001 version of 
> the doc only has the value listed as 64.   This does seem 
> overly restrictive to me, so is this intended to be the 32K 
> value instead of 64?
> 
> 2.16 * 'l' and 2.33 - 'st' * both inherit from 'name' with 
> its limit.  Most of the other items that inherit from 'name' 
> either have the same upper bound defined in X.520, or don't 
> even have their own upper bound definition, just inheriting 
> the value from 'name'.  However, both 'l' and 'st' have 
> explicit upper bounds of 128 given in X.520 (Annex C).  Is 
> there any way to specify that in the definition given here?
> 
> 3.2 - "C" - If we are deprecating the 'searchGuide' 
> attribute, why is it still part of the Country definition 
> (and enhanceSearchGuide is not?)
> 
> 3.8 * "organization" * since it has the identical set of  
> attributes in the MAY list as "organizationalUnit", and the 
> list of attributes on "organizationalUnit" appear to be 
> listed in alphabetical order, why is the same list of 
> attributes given in apparently random order for "organization"?
> 
> Generally speaking, is there some reason not to list the 
> attributes of a class definition in alphabetical order?
> 
>

---

From: Michael Ströder <[email-masked]>
Date: Mon, 19 May 2003 12:06:33 +0200

Steven Legg wrote:
> In X.520 the limit is an upper limit on size,

Why was the sematic of this changed in LDAP? IMO it does not make sense to 
define a "minimum upper bound" at all. I'd rather consider the term to be a 
paradox.

> the upper bounds to avoid confusion.

+1

Ciao, Michael.