Subject: SASL mechanism registration issue

From: John Gardiner Myers <[email-masked]>
Date: Mon, 4 Nov 1996 19:03:31 -0500 (EST)

The ietf-sasl mailing list is now accepting posts.  The draft SASL
specification is draft-myers-auth-sasl-05.txt.

The first issue we have to deal with is the registration procedure for
SASL mechanisms.  Section 5 of the internet-draft currently
establishes a first-come first-served registry for SASL mechanims
names, keeping the issue of the standardization status of particular
SASL mechanism as an issue orthogonal to its name.

Some people have stated that the namespaces for standardized and
private mechanisms should be segregated.

I believe segregating the namespaces will lead to repeats of problems
we have already had with segregated namespaces, whereas we have had
good experience with combined namespaces.  A copy of a message I have
previously sent on the topic follows:

Date: Mon,  7 Oct 1996 18:09:56 -0400 (EDT)
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: Re: SASL

Ran Atkinson <[email-masked]> writes:
> I support Ted's suggestion.  The de facto reality is that if an
> experimental/private namespace isn't made available, some implementers will
> just take (without asking IANA or IESG) part of the namespace for their own
> use.

Said implementers will just take whatever namespace they want without
paying attention to experimental/private namespace distinctions.  I
don't follow your logic: how is segmenting the namespace going to lead
to these people registering their names?

> There is significant historical precedent (predating but including MIME) in
> various IETF standards for the "X-" prefix to be explicitly set aside for
> private uses or experimental uses.

There is significant experience with problems caused by this "X-"
prefix.

Over in the NNTP WG, they're right now facing the problem that there
are a number of commands, such as XOVER, which are in wide deployment
and which should be standardized, but which have a name in the wrong
namespace.  Changing the name would cause widespread disruption in the
installed base.

[[Irrelevant paragraph removed.]]

In ESMTP, the specification had to at one point be changed
retroactively to allow Experimental extensions to use the non-X
namespace when it became apparent that there was no other way for an
experimental extension to later become standardized.  There is still
the lurking problem that some day the X- namespace issue will prevent
a private ESMTP extension from being standardized.

There is significant historical precident for permitting private and
standard protocols to share the same namespace, using registration to
prevent conflicts.  A quick scan of the IANA registries shows as
examples:

        * The TCP/UDP ports
        * The various DNS parameters
        * IP options
        * Telnet options

-- 
_.John Gardiner Myers   Internet: [email-masked]
                        LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

---

From: "Paul E. Hoffman" <[email-masked]>
Date: Tue, 5 Nov 1996 09:09:14 -0800

>specification is draft-myers-auth-sasl-05.txt.

For everyone's information, the most current version of the spec is always
available at <http://www.imc.org/draft-myers-auth-sasl>. This gets updated
whenever the Internet Drafts site gets updated.

--Paul E. Hoffman, Director
--Internet Mail Consortium

---

From: Chris Newman <[email-masked]>
Date: Tue, 05 Nov 1996 09:17:29 -0800 (PST)

> previously sent on the topic follows:

I agree that the "X-" convention has caused numerous problems and
uglyness.  I don't wish to see it continue.

On the other hand, I think it is important to distinguish published
non-proprietary authentication mechanisms from vendor specific proprietary
or patented solutions.  While there hasn't been much experience in the
area, I happen to find the new rules for media types attractive (minus the
historical X- garbage).  Specificly have a "vnd." prefix with a trivial
registration requirement, and reserve other names for protocols intended
for wide deployment with a published specification.

		- Chris

---

From: "Paul E. Hoffman" <[email-masked]>
Date: Tue, 5 Nov 1996 09:09:14 -0800

---

From: Chris Newman <[email-masked]>
Date: Tue, 05 Nov 1996 09:17:29 -0800 (PST)

- Chris