Dear ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
I'm wataru(_at_)ntttsd(_dot_)ntt(_dot_)jp in japan.
I've made some unofficial patches for:
vn
elm v 2.3, 2.4
gnus
to use iso-2022-jp in unstructured fields and
posted them before to fj.sources, a cathegory
in japanese net-news, as like comp.sources.
Thank you very much Wataru-san.
As I requested to a ML where people with real experience on
Japanization of various tools of Internet/UNIX are discussing
on easy way of Localization and/or Internationalization, some
has responded, even though we (including me) can't use English
so well.
So, the fact of the life is that, we, real users and implementors,
don't need MIME charset so much for localization and that we don't
need MIME charset at all for the internationalization. We may support
them partly because they are draft standard and partly because it is
not so harmful, which does not change the fact that it is not so
necessary.
We don't have to remove it from MIME, but we shouldn't force it
outside of MIME.
That is the clear consensus of us, those who have some real
expertise.
This can be taken that other iso-2022 encoding than US-ASCII
should be encoded into a form of MIME.
This makes us difficult to communicate with the *simple* format
defined in rfc822. I believe that the policy of rfc822 is
to exchange messages in a simple format.
Yeah, don't make simple thing complex.
wataru(_at_)ntttsd(_dot_)NTT(_dot_)JP (Wataru Kawakami) insists that
Kana/Kanji-characters
are the PLAIN-TEXT-character for japanese. Come the day that nobody complain
the usage of ISO-2022-JP characters, such as in ``Subject:''.
(request to ISO-2022-in-header:
iso-2022-in-header-request(_at_)ntttsd(_dot_)NTT(_dot_)JP)
Masataka Ohta