ietf-822
[Top] [All Lists]

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt

2002-02-01 19:42:57

I think that's an (unintentionally) misleding way of putting it.  The
recommendation is that when someone gets ready to *deploy* a protocol over
e-mail outside of the originating organization or test base, they should
use a non-X name; in other words, as soon as people start putting
recognition of that name into normal software on a non-test basis, use of
the X name is inappropriate since it then creates unnecessary work in
future standardization.

I guess I wonder - is the burden of "unnecessary work in future 
standardization" consistently worse than the burden of dealing with
poorly-designed features that are widely deployed?  Certainly the
latter cases *me* more pain, and I know of a lot more of the latter
than the former.  But I'm thinking about email, not netnews or HTTP.
By being more concerned about "future standardization", than 
poorly-designed features, I think we'd be optimizing the rare case.

We had a similar discussion regarding SMTP extension names, and I 
like the compromise we came up with - SMTP extension names can be
reserved with either a standards-track document, or an experimental
document with IESG approval.  That allows extension names to be 
reserved for proposals that are publicly documented and have had 
a basic sanity check even if they're not deemed ready for prime time -
but if the extension proves worthy of standardization without 
incompatible change, the same extension name can be used.

But by the time the protocol extension reaches that point, it should
*already* be an I-D and the IETF consensus process can begin.

I'm not terribly concerned about proposals for which there is 
documentation and some consensus - even if it's not considered 
to meet 2026 requirements for proposed.  I'm much more concerned
about ad hoc extensions that some random person thought was a 
good idea but didn't bother to publish and/or get review.

Keith