I have also tried to suggest a 'middle ground' which would allow
easier and faster registration of extensions while still providing
community review. While I'm not entirely comfortable with this
proposal, I do accept that it can take a long time to get an RFC
published, and that this can be a barrier to deployment of useful
new features. We've had some success with other 'expedited review'
processes for other kinds of protocol extensions (charsets,
content-types), and I what I proposed is similar to those mechanisms.
If no RFC is published, where would the specification of the
new header name be stored? It should be easily accessible
to anyone. Can it be stored in the header name registry itself?
I think that specs for new header fields should be published as RFCs.
Would you accept registrations of "warning signs" of header names
not recommended (with explanation of why)?
Hmmm. If someone tries to register a field and there is consensus
that its use should be discouraged, I have no problem with that. If
someone tries to register a field because he wants to discourage
its use, I think we still need consensus that the use of the field
should be discouraged before we put that in the registry. I don't
want the registry to make any recommendations purely on advice of the
person who submits a registration.
Would you accept registration of "no consensus" where a header
name is registered together with the different views on how this
header should be used or not used?
I think that would be necessary. It's better to say "no consensus"
than to recommend or discourage when no consensus exists. Ideally
in that case there would be some summary of the various positions.
But the process needs to encourage consensus, with the statement of
differing opinions used only as a last resort.
Keith