ietf-822
[Top] [All Lists]

Re: X-* header fields

2004-01-18 10:15:21


Bruce Lilly wrote:

>
> 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:

[...]

> So what's so abhorrent about top-level X- fields (RFC 822) that
> doesn't also apply to
> charsets, media types, language tags, etc.?

I didn't intend that to stifle discussion, but I haven't seen any
responses from the anti-X-
community.  I did intend it to be a moderately strong case in support of
X- fields (by
way of asking what's so bad about them that differs from charsets,
language tags, etc.).

In the case of media types, x- values have proved to be a very poor idea, in
that their use has in some cases prevented registration of types that really
needed to be properly registered. And note that media types are, generally
speaking, something that implementations support through the use of a
configurable table, which means the adverse impact on interoperability of
multiple labels is much,  much lower than something that tends to be embedded
in program code. However, abandoning the x- distinction in the case of media
types is highly problematic at this point because of the political issues
surrounding the registration process and the history of its development. Header
fields do not have a registry at present and hence do not have this problem.

I haven't seen significant use of x- types in either charsets or language tags.
In the case of charsets the early registration of a massive number of charsets
is likely what prevented this from  happening, along with the willingness,
right or wrong, to simply use non-x- names without registration. Language tags
started out with a reasonably comprehensive set of initial registrations and a
reasonably timely and fair review and approval process. (Of course there's also
the fact that defining a new language is a much bigger deal than coming up with
new item for most of of the other registries we have.)

I can argue the effects of x- tags in the content-transfer-encoding
space either way. On the one hand, the ability to use various x- tags
for various uuencode variants made it possible to use uuencode as
transitional encoding on the way to getting base64 support in place. On
the other hand, the lack of a standarized label did cause fairly
nontrivial interoperability problems along the way. Does the end justify
the means?

The bottom line is that the success of x- fields in other places has anywhere
from disasterous at worst to mixed at best. And to a large extent the lack of
harm in many spaces has come from lack of use. So if you're looking for support
for keeping the X- distinction from the successful use of X- in other contexts,
I'm afraid it is not forthcoming.

                                Ned



<Prev in Thread] Current Thread [Next in Thread>