<<< From: Masataka Ohta
<<< The problem is that neither 822 nor MIME addresses the issue of I18N.
<<
<< From: Tony Hansen
<< As you say, 822 was never intended to address the issues of
<< internationalization. So don't expect to be able to do
<< internationalization within its framework. PERIOD!
<
< From: Masataka Ohta
< Regardless of what the original intention is, RFC 822 is already used for
< the framework of the internationalization. PERIOD.
First you say that raw rfc 822 doesn't address internationalization, then
you say that it IS being used for internationalization. How contradictory.
By your own definitions, it would be more accurate to say that raw rfc 822
is being used for the framework of localization, but not
internationalization.
There are several groups who are trying to do email internationalization on
the Internet. Some of these groups are attempting to shoehorn
internationalization into raw rfc 822 in various ways. (The
Japanese-speaking people whom Mr. Ohta is purportedly representing appear to
be in this "shoehorn" group.) Some of these groups have attempted to extend
rfc 822 in their own ways to achieve internationalization. (These groups
appear to be disappearing.) And some of these groups are attempting to make
use of existing already-agreed-upon extensions (MIME) to rfc 822 for the
framework to achieve internationalization. These groups aren't using MIME to
do internationalization, but are using MIME to support internationalization.
<< MIME only covers MIME comformant e-mail.
<
< If you use MIME, no one will be able to complain about your use of
< iso-2022-*. If you don't use MIME for your iso-2022-* email, expect lots
< of complaints. End of story.
<
<< No, we don't use MIME for everything.
There's an old adage that if you're not part of the solution you must be
part of the problem. Think about it.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony