Keith's proposal is a very interesting one and I'll discuss the
pros and cons.
First I'd like to remove one difference between his proposal and the
current mnemonic proposal. I will add the Q encoding to the legal
encodings for Header-charset and extend the encodings to apply to
atoms. I requested a while ago that the quoted-printable lead-in
character be changed so that we could have encodings in atoms, but
when nothing happened I gave up. Keith has solved the problem nicely
by introducing a new encoding. I expect that if either Keith's proposal
or the mnemonic proposal get up then the Quoted-printable encoding
will be slightly modified so that there don't have to be 2 similar
encodings. [By the way I don't know whether Ned would support this
change to the mnemonic header proposal.]
One nice feature of Keith's proposal is that it doesn't introduce
any new headers. This particularly means that you can process a message
sequentially without looking at all the headers before you start to
display any of them. It also is much more resilient against the sort
of bugs that John Klensin has warned us about. There is a cost which
is high if you are religious about these things and very low if you
are practically-minded. Given that we are the Internet not the other
mob we should be the latter.
The cost is that Keith's proposal retroactively changes the meaning
of existing rfc-822 mail messages whose meaning is completely defined
by rfc822: i.e. messages that don't have any extra headers. In fact
if I got it right this is a message whose meaning would be changed,
since I put one of his funny atoms in the header. In my opinion this
is not a serious drawback of Keith's proposal. After all it only
changes the display characteristics, and the probability of any
real message being changed is simply infinitesimal.
I have rated Keith's proposal a win when it comes to new software
that will handle extended character sets in headers. In that case
it doesn't matter how ugly it looks since the users will not see
the encoding. On the question of how it will interact with existing
software it has some losses and a very big win.
The losses are:
(1) it looks horrible to the recipient with a dumb existing mailer [but
none of the proposals are perfect in this regard].
(2) some existing practices (e.g. using iso-2022 in Subject in Japan,
and probably using 8859-1 in various places in Europe) are easily
legalized by the our proposal -- just add a Header-charset line and
keep at it.
The win is this: You get a message from someone using this convention
in a header. Your mailer knows nothing about the convention. But you
do "reply" and the software sends a message back to the sender and
also copies go to other people that you nominate: and your software
has automatically included the funny atom in an address or subject line.
Now when the message gets back to where the convention is understood it
immediately becomes operative again. By contrast anything with new
headers in it is going to fail badly in this situation.
Obviously Keith's proposal has no problem with combining headers from
different places. In fact it is by far the best at this: no question
of upgrades, or of renaming clashing variables.
I still prefer the mnemonic proposal for the hidden agenda. It will
encourage the use of mnemonic and software which knows how to convert
local character sets to (and from) mnemonic. This use of mnemonic
will improve communication between different character set environments
and between the new world and the old in various ways.
However I think it is a close call and those who don't share my hidden
agenda won't find it close.
Obviously mnemonic can be used with Keith's proposal. It just needs
a magic code.
Bob Smart