Here's another take on the subject (I hope it doesn't open up several cans
of worms, but here goes...)
X- is used as an indicator for experimental or private-use tags in many
places
in Internet message protocols other than field names. For example:
charsets (RFC 2978, sect. 3.1, also RFC 2046, sect. 4.1.2)
MIME media types (RFC 2045, sections 5 & 5.1, also RFC 2046, section 6)
and subtypes
language tags (RFC 3066, section 2.2)
disposition-notification options (RFC2298 section 2.2 )
transfer encodings (RFC 2045, sect. 6.3)
MTA-name-types (RFC 3464 sect. 2.2)
access-types (RFC 2046 sect 5.2.3.1)
address-types (RFC 2298 sect. 3.1.2, also RFC 3464 sect. 2.2)
dispositions (RFC 2183 sect 2.8)
diagnostic types (RFC 3464 sect. 2.2)
disposition modifiers (RFC 2298 sect 3.2.6.3)
And is mentioned in Keith's auto-response draft for auto-submitted types
-- and I don't recall
any discussion about that here when that draft was recently discussed.
And of course there are MDN X- fields (RFC 2298 sect. 3.3) and DSN X-
fields (RFC 3464
sect. 2.4).
So what's so abhorrent about top-level X- fields (RFC 822) that doesn't
also apply to
charsets, media types, language tags, etc.?
And yet another feature of X- fields:
RFC 2047, section 5 notes that encoded-words may appear in X- fields.
In all
other fields, it is necessary to know the syntax of the field in order
to know
whether and where encoded-words are permitted. I.e. when displaying fields,
one may decode an encoded word in an appropriate place in a field body
if the
field syntax is known, and one may decode an encoded-word in any X- field
(presumed to be unstructured), but one may not decode anything which has
the form of an encoded-word in an unrecognized field (other than an X-
field).