[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: limits (Was: IETF ldapbis WG Last Call: draft-ietf-ldapbis-iana-04.txt)
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