As the debate over non-ASCII headers has raged on, I find myself more
and more drawn back to one of my earliest proposals in this are, the
"encoded-variable" approach. After reading Harald's latest proposal
(which is thoughtful and well-intentioned but still has problems, most
notably the inability to mix character sets on a header) and after
getting only one negative response to my earlier question ("was
encoded-variable such a bad idea?") I've decided to dust off this old
bird and see if it flies.
Let me state my position on this simply as being an all-or-nothing one.
If we want to do this stuff simply, quickly, easily, and (reasonably) safely,
the only alternative is to go with a reasonably universal encoding that
covers a wide range of character sets and looks reasonably nice to unextended
viewers. This is essentially the "just use mnemonic" proposal that Bob Smart
and I, among others, have advanced.
If we really think this is inadequate (and I for one am not convinced that
it is) then I think this approach of Nathaniel's is nearly the only one that
will do. Once you let more than one character set in to play you have to be
able to have more than one in a single header. More generally, you need to be
able to have more than one set and encoding. You also need to allow for
composition and reconstruction of headers by UAs that do not grok all this
stuff. All these concerns lead directly to schemes like this.
This scheme is also reasonably safe, and correctly implemented it should be
somewhat more resilient than simply using mnemonic (but not much).
I can live with either of these proposals -- I was not against this
full-featured proposal when it came out. The Europeans on the list at the
time were against it, as I recall. Proposals that lie somewhere between the
two do not have my endorsement -- if we are going to bite off more than minimal
extensions (aka just use mnemonic) we might as well do the whole thing.
Ned