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

[Ryan Moats <rmoats@lemurnetworks.net>]

On Thu, Nov 29, 2001 at 10:22:10PM -0800, Kurt D. Zeilenga wrote:
| 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?

Because I've seen far too many cases where what was originally thought
to be "enough space" ran out.  While, I don't see how 48 characters
arises from the I-D guidelines, I'm willing to let other's in the WG
give their opinion (realizing that silence is assent).  However,
16 strikes me as too short.  If I look at DNS, a comparible limit there
is 32, so why not that?  Given the history of DNS, I would then agree that
there would be "plenty of space".

Ryan