> I wouldn't go that far. Certainly for experimental
> purposes or within a certain community a character set
> that still hasn't been registered should be possible to
> use. But in that case the use of a charset value starting
> with "x-" (and therefore guaranteed to never be
> registered by IANA) should be required by the HTTP 1.1
> specification, as it always has been in MIME
> specifications.
No. The MIME specifications have always been broken for that reason.
RFC 1521 required behavior that no implementation ever obeys --
that being a check of the IANA registry before transmission of a token
which is not prefixed by "x-". Requirements which serve no useful purpose,
and which are directly contradicted by all known implementations, do not
belong in any RFC.
Even if such a requirement were added, it is poor engineering to implement
a system that relies on "flag days" in which to switch from existing use
of an x-token to use of its registered non-x equivalent. The result is that
a good implementation treats any "x-" prefix as if it didn't exist, so that
the same application won't die when somebody eventually gets around to
registering that particular token. In other words, a good implementation
does not distinguish between registered and non-registered tokens, and at
that point there is no reason to use the "x-" prefix for anything.
Our experience with "x-" prefixes has been uniformly bad; rather than
encouraging registration of all tokens, they encourage the easy route
of just using the x-token as the standard for that type. I see no reason
to further encourage their use. IANA should certainly continue its
normal behavior of never registering "x-" prefixed tokens, but that
registration process is outside the scope of HTTP.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92697-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/