However, on reflection it does appear that (in particular) quoted-printable
was not as well accepted as was anticipated. People who were used to seeing
correctly formed characters did not react favorably to instead seeing =XX,
even if =XX occurred seldom enough that the text could still be understood.
Then, how can you begin mnemonic?
Use '=' or some other "occurred seldom enough" graphic character?
Or use some control character in non-standard way?
Or use mnemonic even to represent ASCII characters?
Ohta-san's approach
works okay for people who are displaying messages on terminals that support
ISO-2022 escape sequences. Either of them will work if there is appropriate
decoding/display software on the recipient end.
As described in our drafft, MULE (Multilingual emacs) is such an
editor which support all the character sets of ISO-2022-INT-* and more.
The problem is that I'm an vi addict. :-)
Neither of them works well
for everyone, and neither of the schemes will work (without additional
encoding) for message headers.
ISO-2022-JP as is without any encoding is ACTUALLY WORKING NOW completely
well for unstructured message headers. So is ISO-2022-INT-*.
I don't mind so much if we can't use internationalized encoding for the
time being. I don't mind so much either if we must use QP encoding for
the structured headers ONLY.
(By the same token, I think the ISO-2022-INT-* scheme is also clever, and
makes a good solution for a different set of people...but it isn't
sufficiently general to replace either quoted-printable encoding in message
bodies or 1522 encoded-words in headers.)
QP decoding is merely CTE decoding. Further decoding is necessary if
local convention to represent some charset is different from
that used in message, which has been happening in Japan for
more than 10 years. That is, there are several different local
conventions or profiling to represent characters based on JIS X 0208.
One is EUC, the other is pure 7bit JIS (not necessarily ISO-2022-JP).
Shift JIS, which is not purely based on JIS X 0208, is also widely
used on PCs.
Conversion between those encoding systems and ISO-2022-JP is done
widely on all Internet-connected computers. Conversion to local
encoding is necessary anyway.
Thus, using ISO-2022-INT-* does not add anything about the complexity
of local decoding.
But the nice thing about MIME is that it is extensible enough to allow
new character sets and new content-types to be defined...
The problem is that it is not so useful.
You can think of bare MIME as a "worst case" solution. It is somewhat ugly
and it is somewhat painful to migrate to it, but it is also very general and
it provides a smooth mechanism to migrate to future extensions.
Future extension? No, that is the wrong way.
Now is the time to have a dedeployment plan for MIME to REMOVE
ugliness, that is, to REMOVE ugly ffeatures, as much as possible.
Removing charset and CTE should be a good starter.
Masataka Ohta