ietf-822
[Top] [All Lists]

Re: Working code and rough consensus on RFC 822 interpretation

1994-12-03 22:19:32
<< In mathematical terms, this is an axiom upon which all else builds.

< No mathematics please. It's an engineering issue. PERIOD.

Ah, but most engineering depends heavily on mathematics.

If there are two mathematically similar solutions, relying on working
codes results in the best interoperability.

That's why, dispite the ambiguity, I don't think ISO-8859-1 use SI/SO
mechanism.

(After all, YOU'RE
trying to use statistics, another branch of mathematics, to support YOUR
argument.

ROUGH statistics. :-)

I could use the same complaint about YOUR arguments. 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.

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.

Engineering is about dealing with reality. So while the numbers may change
in the future, we must deal with the reality of the world today. And the
reality is that iso-2022-jp-capable displays are in the miniscule minority.

We are reading iso-2022-jp messages at IETF in the terminal room.

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.

When you send a message out to the world using
MIME to switch between different character sets, users with MIME capable
mailers will be able to read most of the message without any problem and
only have to deal specially with the character sets that their displays
cannot handle.

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.

Still, some of us implemented MIME because charset inside (but
definitely not outside) MIME is harmless.

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.

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.

So where do we go from here?

Don't expect so much on MIME charset, but use other useful capabilities
of MIME.

Besides, labelling character sets is such a small part of MIME. The many
other features of MIME are much more important.

Yes.

                                                Masataka Ohta