Re: IANA Considerations for LDAP

[rvh@qsun.mt.att.com (Richard V Huber)]

I can live with that solution.  I just think we need to treat e-
consistently across all types of names (OID names, attribute options,
result codes, and authentication mechanisms).  Your email (as opposed
to e-mail) indicates that you want to have a consistent rule that e- is
used if and only if the name is experimental.  The document needs to be
tweaked to say that; right now it says if, but not only if for two
types of names.

The only argument I can see in favor of of allowing ANY name to start
with e- is that if an experiment succeeds and is documented in a
standard, you could leave the name alone.  But since you would have to
change the associated numeric value in some cases, this would be a
limited advantage.

Rick Huber

: To: rvh@qsun.mt.att.com (Richard V Huber)
: From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
: Subject: Re: IANA Considerations for LDAP
: Cc: ietf-ldapbis@OpenLDAP.org
: 
: At 08:51 AM 4/18/01, Richard V Huber wrote:
: >Should the use of "e-" be restricted only to experimental attribute
: >result codes and authentication mechanisms?  If someone wants to
: >register "e-commerce-auth" as an authentication mechanism in a
: >Standards Action, it is allowed?
: 
: Does x-wife refer to my wife or my x?   :-)
: 
: Of course, e- values doesn't have the same problem as with x- values.
: x- values must never be registered so as that no registered value
: will conflict with a private extension.  Of course, private extensions
: might conflict with each other, but that's a different matter.
: 
: It was my intent to reserve e- to make it clear for all as to
: which guidelines/procedures apply.
: 
: I note that e-commerce-auth could just as easily be named
: eCommerceAuth or eCommerce-Auth.
: 
: Kurt