ietf-nntp IANA extension registry (was: Commetns on draft-15.pdf)

[ned+ietf-nntp at innosoft.com]

> In <01KCK4UU4BXA002Q1H at mauve.mrochek.com> ned+ietf-nntp at innosoft.com writes:

> >> I think the essence of
> >> any form of "provisional" registration would have to be some mechanism for
> >> dregistration for the ones that never make it. Perhaps after six months,
> >> unless in the meantime there was at least an ietf draft in existence with
> >> a view to an eventual RFC.

> >On the contrary, the essence of such a scheme is that the string will then be
> >reused in an incompatible way. If this doesn't happen there is no justification
> >for ever removing anything from the registry, and hence no justification for
> >provisional registrations.

> Eh? Are you suggesting that if the header Foobar: is registered for use in
> the protocol "Foo", but the protocol "Foo" then falls into disuse (or never
> fell into use in the first place) then it should remain registered as
> being associated with that protocol until such time as someone proposes a
> new protocol "Baz", which just happens to incorporate a Foobar: header?

First of all, we are talking about protocol extensions, not header fields.
The two have very different characteristics.

However, even in the case of header fields (for which there currently is no
registry) the issue lies in determining when something actually is no longer
used. Like it or not, people often use very old software. Additionally, use of
odd header fields is often limited to some specific enclave, which makes it
nearly impossible for anyone outside that enclave to know about that particular
use.

I've often heard claims that a particular header field is no longer in use, but
in the cases where it wasn't an obvious case of the support for the field never
deploying in the first place I am always quite skeptical of such claims. And
sure enough, in the couple of cases where I've gone and checked, the claim was
specious.

So the question once again comes down to whether the ability to reuse a
favorite string is worth the risk of a conflict with existing use. I don't
think the risk is worth it in the case of protocol extensions.

				Ned