[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working code and rough consensus on RFC 822 interpretation
> << 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
> (After all, YOU'RE
> trying to use statistics, another branch of mathematics, to support YOUR
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
> Besides, labelling character sets is such a small part of MIME. The many
> other features of MIME are much more important.