Re: [tlug] Japanese Encoding - which one?

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Brett" == Brett Robson <b-robson@example.com> writes:

    Brett> Not /me/, but works for the 100's of thousands of people
    Brett> that receive our Japanese email.

*sigh*  The point is that I don't give a flying Mexican ... uh, I don't
care at all about the hundreds of thousands of people who receive your
mail.  Neither does Lyle.  (Well, Lyle is a kinder gentler kind of
guy, he may care a little in the abstract.  But not like you do!)  We
care about the people we send mail to, and that means our best choices
of communication protocol may differ from yours.  "Works for you" is
still an accurate description of what you said, even though you are
communicating with maybe 100 times as many people as I do.  That only
matters to you; your customers are not my problem.

If our personal circles happen to accept UTF-8, then the RFCs say
absolutely nothing against its use.  As Gabor Farkas pointed out, even
RFC 1468 doesn't say any one SHOULD use ISO-2022-JP, even for Japanese
text.  RFC 1468 uses SHOULD only when talking about _how_ to use
ISO-2022-JP: you SHOULD use BASE64 not quoted-printable, you SHOULD
NOT break MIME-words in the middle of a character, you SHOULD NOT use
H as a final byte because that has been standardized to mean something
else, you SHOULD NOT use JIS Roman in place of US-ASCII.  With respect
to the appropriate use of ISO-2022-JP, it merely says that this is the
encoding that is used on JUNET---which doesn't exist any more.  We're
all part of The Internet, where the standard (to the extent that there
is one) is Unicode, usually UTF-8.

Why does this matter?  Because as a person involved in system
management and customer education at a major ISP, you have a
responsibility to be part of the solution, not part of the problem.
That involves understanding what standards are, and how they are used.

There is a painful tradeoff here for Japanese.  They can use what they
have historically used (and even that is merely probable---I still
occasionally get raw Shift JIS in the headers from non-spammers), and
have a high probability of communicating with other Japanese.  Or they
can take kokusaika seriously, and use Unicode, which is the
international standard (only the Japanese, the Chinese, and the
Koreans ever took ISO 2022 seriously, and AFAIK none managed to
implement the standard universally, cf Shift JIS, Big5, JOHAB).

I don't think anybody with an interest in getting this country moving
forward denies that Unicode is the way to go in the long run.  The
problem is that the transition is painful and somewhat unfair in the
short run, and the long run is a sequence of short runs.  So until we
actually do switch to Unicode wholesale, we're going to face that
painful tradeoff every day.

It doesn't help the situation for someone who SHOULD know better to be
claiming that the standards say we SHOULD use ISO-2022-JP.  What needs
to be said is that we are in a process of transition from one standard
(local prevalent) to another (globally useful).  And it helps to
measure the amount of pain involved, but we also need to remember that
different people face different amounts of pain.  And the only way to
decrease the pain is to increase the number of people who can handle
the coming standard.

So, for example, I think it would be a good idea for TLUG to encourage
UTF-8 mail.  Everybody here has a system that can handle it (although
it might involve changing MUAs), everybody here has (more or less)
interest in learning how to make it work.  Sure, some people will find
it more or less inconvenient, but that's generally going to work out
to be an investment, not ijime.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.