again, I don't think pulling the plug is the right mechanism.
nothing should go in the registry without public comment and
explicit approval.
I gave a long argument as to why this accomplishes exactly the
opposite of what you say you want. Prior approval *causes*
deployment of bad mechanisms without ever documenting them.
I think that's an exaggeration. It's true that if the approval
process is too onerous then more people will try to bypass the
approval process than otherwise. But that doesn't inherently
cause the wide deployment of bad mechanisms. OTOH, if the
approval process is too easy then the bad mechanisms get approved,
and there's less to discourage other vendors from implementing them.
Some bad mechanisms are going to get deployed no matter what we do.
I think it should be easy to apply for approval of a header field,
in the sense that the process is visible and that the considerations
for approval are also visible and well-documented.
I think it should be easy to get approval for a header field that
is well-defined and not disruptive.
I don't think it should be easy to get approval for a header field
that is disruptive.
I also think we should be able to document header fields that are
observed "in the wild" absent approval - but they should be listed
separately, or in such a way that it's very clear that no approval
was obtained. Another reason for documenting these separately is to
get a sense of the degree of deployment of standard header fields.
What I currently have in mind is something like the following:
1. have a template to request registration of a message header,
much like the templates for content-types, charsets, or URN NIDs.
the template explains the information that is required in order
to register a header field - including the field name, the purpose
of the field, abnf syntax, security and privacy considerations,
the set of protocols for which the field is intended, etc.
2. have a single mailing list for public discussion of all
proposed message headers
3. submission of the form causes an announcement to be sent to that
list, opening discussion of that header field.
4. initial review takes place for a fixed period of time - say 2
or 4 weeks.
5. at the end of the review period a designated expert makes one
of a small number of recommendations:
- field is believed to be non-disruptive and okay for
experimental use, or
- field is insufficiently documented, or
- revision based on review feedback is required, or
- IETF consensus is required before this field can be registered
6. "in the wild" observations are maintained separately, and
perhaps, automatically. these are submitted via an emailed
web form. submission of the form causes an automatic reply
to the email address that submitted the form; the sender must
confirm sending the observation before it will be accepted.
7. there also needs to be a process for commenting on existing
header fields and their applicability. this might be as
simple as writing a BCP about the header field, but the
information in that BCP needs to be reflected in the registry.
Keith