Re: limits (Was: IETF ldapbis WG Last Call: draft-ietf-ldapbis-iana-04.txt)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:52 PM 2001-11-29, Ryan Moats wrote:
>On Thu, Nov 29, 2001 at 03:58:42PM -0800, Kurt D. Zeilenga wrote:
>| At 02:07 PM 2001-11-29, Ryan Moats wrote:
>| >On Thu, Nov 29, 2001 at 01:44:05PM -0800, Kurt D. Zeilenga wrote:
>| >| At 10:19 AM 2001-11-29, Ryan Moats wrote:
>| >| >1. Several searches on the ldapbis mailing archives failed to show any
>| >| >discussion on the limits on protocol descriptors and option strings.
>| >| >I for one am uncomfortable with applying such limits without more discussion.
>| >| >Rather, once the requester has met the "SHOULD" consideration, I don't
>| >| >think IANA should be given the right to arbitrarily refuse a request just
>| >| >because of length. 
>| >| 
>| >| Well, I would argue that IANA should have the right to refuse
>| >| a request solely the item is too long.  What this sentence does,
>| >| is give the requester and the IANA guidance as to what lengths
>| >| MAY be considered too long.
>| >
>| >I disagree.  Assigning a "MAY" limit creates (to me) an arbitrary limit
>| >in an unlimited field.
>| 
>| The bottom line is that we need to provide requesters, reviewers,
>| and the register (who often is the sole reviewer) guidance as to
>| what is "too long" (or not "short").
>| 
>| I'm prefer the current language:
>|    IANA MAY refuse to register any descriptor over 48 characters
>|    in length.
>| 
>| but would fine with:
>|    Any descriptor over 48 characters MAY be viewed as too long to
>|    be registered.
>| 
>| If neither is acceptable, do you have a counter suggestion?
>
>I'm still struggling with the '"SHOULD" be short' phrase to begin with.
>As the document says, I don't see any reason for this in the protocol
>specifications themselves, so my proposal are:

The "core" specification didn't make any IANA considerations.  But,
I did take "short" from the RFC 2251 statement: "... identified by a
short descriptive name and an OID (object identifier)."   It used
only once (with regard to attribute types), but the rationale for
short names applies to all identifiers used in the protocol and
elsewhere.  But I note that what this I-D provides is registration
guidelines, it doesn't restrict what can or cannot be used in
the protocol.

The short statement and length guidance is an IANA consideration.
They are aimed at making the registries management without placing
undue restrictions upon protocol/schema designers.

I choose 48 characters for descriptors as it hard to write a
specification for a descriptor of greater length than that (given
I-D guidelines).  I choose 16 for options as it hard to write a
specification for options of greater length (especially when one
considers detailing interaction with other options).  There are
other practical considerations, such as the ability to publish
the registries in table format printable on a normal width
computer terminal.

As 48 and 16 allow for huge number of descriptors/options to be
registered, I cannot imagine any need for longer descriptors/options
to be allowed.  Why do you think longer names should not be viewed
as too large to register?

Kurt