Well, I think the CJK people are not the people to care for
when we are talking fallback notation. The CJK people will
have 2022 support anyway and thus have the right stuff for their eyes.
The Japanese cannot use 2022 in the headers. That's why the solution
for the headers must also solve the Japanese problem in a reasonable
way.
But the MUAs can handle the CJK stuff and translate some encoding,
say quoted-printable or mnemonic into the right stuff.
I think it is not really possible to read CJK without having
the adequate hardware support to present the characters.
Then we can discuss what is the best way of presenting CJK
on an avarage dumb US/Danish/Russsian/Greek terminal.
How about something like "Yasushi Nakahara"?
That may be better, if you like romanisation.
But then, how can we specify things like that,
knowing that we have CJK 2022 in the first place and that we then
want a fallback solution that can be presented on average dumb
terminals?
I have several ways of doing things like that up my sleeve.
I have romanisation tables for CJK.
I have some pattern description for CJK.
I have dictionary numbers for CJK.
Would any of these be better than the <charset><row><column>
names?
One advantage of the current mnemonic CJK naming is that
you can see that it is CJK, and if you have the CJK tables,
you can look up the right character easily. Mnemonic CJK is
now in the form <character set><row><column> eg j1756 for
some Japanese ideographic character.
Yes, but who wants to look up characters in tables just to read
someone's name? For you it's OK. You can read J&o/rn without looking
at a table. But for the Japanese, it's not OK.
Yes, but how can we do it better?
Anyway on CJK equipment as said above, the MUA should turn
the fallback representation into correct 2022 sequences.
Keld