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