Mulling some more, I do see a potential problem that you may be alluding
to, and have another thought. Allowing provisional registration of non X-
headers might be seen as tacitly acknowledging that it's OK to use them
without standardization, regardless of what the protocol spec may say.
This matter has recently been discussed extensively on the USEFOR WG. The
opinion seems to be that X-headers are more trouble than they are worth
(especially if they come into widespread use and widely deployed software
contains code that recognises them). It is also noted that RFC 2822 no
longer distinguishes them as a special case.
Current thinking on Usefor (as reflected in the current draft) is that
X-headers are appropriate for informative headers that are intended only
for human consumption (or for 'vanity' headers, and the like). There is a
blanket ban on standardizing them. And the recommendation for someone
devising some experimental protocol that is expected to require code in
widely-deployed software is to use a non-X header, whatever any standards
might say. There are dangers in this, but it is regarded as the lesser of
the two evils.
X-headers are very useful for experimental features and private agreements -
i.e. for the kinds of things where you need a new field - but because it
isn't going to affect many people, there's no need to go through the review
process. For similar reasons, they're okay for write-only fields even if
they are widely deployed.
IMHO X-headers for read/write fields shouldn't be used in widely deployed
code. If you need a new read/write header field for code that is going
to be in widely deployed you need to get consensus on that field name
before you deploy it.
However for a vendor that refuses to get consensus, using a X- field for a
proprietary extension is less of a crime than using a field name that
doesn't begin with X- for a proprietary extension.
Keith