<< Also, it's interesting how you use examples of MTA's to make arguments
<< about MUA's.)
< Huh? All (almost all? maybe) MUA's today pass ESC. All MUA's pass
< non-ASCII ISO 646.
Passing characters is an MTA capability. Accepting characters from the user
and displaying messages on the screen are MUA capabilities. I know of a
number of MUA's which do NOT accept escape sequences, or even sequences
which contain many other control characters. So your statement is false.
<< Consider the number of computers which can display us-ascii, which can
<< display iso-8859-x, and which can display numerous other character sets.
<< Then consider the number of computers which can display more than one
<< character set. Then consider the number of computers which can use
<< iso-2022-jp to switch between those multiple character sets.
< Mostly same. All X capable terminals can do all of them.
X capable terminals are not the norm around the world. They are certainly
becoming more common, but they're not yet prevalent. Of the 8 or so
computers I use regularly, only one of them has an X terminal.
< We are reading iso-2022-jp messages at IETF in the terminal room.
On an X terminal no doubt. So? The IETF is technologically rich, as compared
to a large portion of the world.
<< When you send your iso-2022-jp messages out to the world without any
<< labelling, the vast majority of the displays in the world are incapable
<< of handling that message. When you send your iso-2022-jp messages out to
<< the world with a MIME label, recipients of that message on
<< non-iso-2022-jp displays, but with MIME capable mailers, can recognize
<< what the message contains and act accordingly.
< Users see the same result, the garbage with some clue on character
< set/charset used but not supported.
No, the MIME label allows them to not see any garbage at all. They can
choose to not display anything in a given character set. Or they can decide
that they need to send their message over to another machine which can
handle iso-2022-jp. Or they can decide to do lots of other possible things,
all because they know a priori that the message uses iso-2022-jp.
< Today, we, Japanese (including those living abroad), send out and receive
< messages to/from the world (both Japanese and non-Japanese) NOT using MIME
< and be able to read most of the messages without any problem and only have
< to deal specially with the character sets that my displays cannot handle
< (in most of which case, I, anyway, cannot understand the content).
<
< The reason is that ISO-2022-JP is designed comformant to RFC 822 and upper
< compatible to US-ASCII.
<
< That's why, dispite MIME designer's intention, there are not so much need
< for charset.
But the opposite is not true. You may be able to handle most of the world's
messages, but most of the world cannot handle your messages. Which is why
there is a definite need for you to label YOUR messages.
< Still, some of us implemented MIME because charset inside (but definitely
< not outside) MIME is harmless.
Now we're getting somewhere. At least you've agreed that using charset
within the MIME framework is harmless; that's a start.
<< When you send a message with multiple character sets using either
<< iso-2022-jp OR MIME, users without MIME capable mailers in the majority
<< of the world will see garbage on the screen.
< Users with MIME capable mailers see the same garbage.
You just don't get it, do you. Users with MIME capable mailers at least have
the choice to do something with the message without having to see any
garbage. Users without MIME capable mailers do not have that option.
<< I think that the majority of the people on this list feel that most users
<< around the world will be able to upgrade more easily to MIME-capable
<< mailers than they'd be able to upgrade their displays to handle all other
<< types of character sets.
< Wrong. Without such displays, we can't even edit messages.
Without such displays, YOU cannot edit your iso-2022 messages. However,
other people (possibly using numerous other character sets) will certainly
be able to do lots of useful work.
Mr. Ohta, you and I see a far different evolution of the email world in our
crystal balls. It will be interesting seeing who is right.
<< Besides, labelling character sets is such a small part of MIME. The many
<< other features of MIME are much more important.
<
< Yes.
At least we're in agreement on something!
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony