Well, if most of the characters are in fact ASCII, you can then us
quoted-printable, right? And troublesome characters like NUL can be
encoded using either quoted-printable OR base64, right? I still don't
see why 16-bit text needs to be handled any differently than any other
binary data.
If you used Q-P on straight Unicode, it would look like
=00t=00h=00i=00s. If you used Base64, it would look like
AHQAaABpAHM=, except that you wouldn't be able to read any other part
of this message either, since Q-P and Base64 encode the whole body
part.
In email, there are two basic requirements:
(1) transmissibility
(2) readability
MIME's Q-P and Base64 take care of (1), but until many people actually
have MIME decoders installed, (2) suffers. It seems to me that this
is the raison d'&e>tre of Keld's "mnemonic" method. In reality, we
probably have to strike some sort of balance between (1) and (2).
It'll be interesting to see just how fast MIME decoders get installed,
and whether readability will then become less of a requirement.
... to have a character set something like "ISO-10646-UTF-2" ...
Whoever writes this document may want to call it something like "UTF2"
instead, to keep it short so that it can be used in RFC1342 headers
without excessive increase in line length.
ISO-2022-JP seems to have become established as a name, and I
sometimes regret this...
Cheers,
Erik