I may have some 200.000 combinations of CJK characters that should
uniquely define words and meanings for CJK.
So email software should parse Japanese? This is not simple enough, in
my opinion.
I did not make the collection (my CJK expert did), and it may be more
oriented towards Chinese. Anyway it has not proved to be operationable.
But it could be investigated further, if people found it was
a theorethically viable solution for one or more of the CJK languages.
Anyway parsing two characters into something that can be handled is
more-or-less standard with the upcoming POSIX charmap and UNICODE/10646
specifications.
Another question: would Naka1 not be associated with the right
CJK character?
No. The Japanese don't have any "Naka1" system, so they would not be
able to make the association.
I know that there is no Naka1 system in common use. But a couple of years
ago there was no X Windows kterm input method either, and now it is
widely accepted. Could something like that also happen with email?
Could something like kterm IM be used instead?
Now, having said that Japanese text must be in a particular form of
ISO 2022 for it to be readable, I should also say that ISO 2022 cannot
be used in email headers, because it can contain unquoted special
characters like '<', '(', '"'. (And quoting would distort the
ideographic glyphs.)
It is true that quoting parts of 2022 CJK encoding, which happens to
be ASCII 822 special characters, makes the 2022 string unrenderable.
But the thing to do here is then to do the unquoting - in a seperate
pass over the string. This may affect current CJK MUA software which
expects 2022 encoding to be directly displayable.
Using quoted-printable or mnemonic would not have this impact on
current CJK equipment, as it would just be ASCII to them.
And thus new software can have the new capability, while
the old cannot - although the old SW will not be broken.
So it would be an advantage not to use 2022 schemes
in fields that need to be quoted for existing CJK software.
Keld