ietf-822
[Top] [All Lists]

Re: Working code and rough consensus on RFC 822 interpretation

1994-12-04 21:53:50
<< 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.



Relaying messages is an MTA capcbility. Passing characters from the
message to display or user agent programs is for MUA.

These days, there are few , if any, MUAs which does not pass ESC.

<< 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.


Where are you living? Today, most computers are X capable. Some are IBM PCs
on which MULE runs. Most of the rest can display ASCII only.

< 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.


So? IETF use AV multicast which can not be seen from technically pooor
part of the world. Should we stop developing multimedia
environment?

Note that I could have accessed Japanese mails in INET and in SIGGRAPH also.

<< 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.

You can do the same thing with ISO-2022-JP or ISO-2022-INT-*.

They can
choose to not display anything in a given character set. Or they can decide

But, rational implementaions try to display something hoping the display
server knows how to display the CTE decoded result.

that they need to send their message over to another machine which can
handle iso-2022-jp.


Wrong. Whether iso-2022-jp can be displayed or not is determined
by the display, not by the machine which spoolsmessage.

If you use iso-2022-jp-capable-at-the-console machine through ASCII
terminal on RS232C, you can't see iso-2022-jp.

Or they can decide to do lots of other possible things,

I'm afraid you only have a lot of illusions.

< 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.

I do handle most of the world's message, because they are using ASCII.

Which is why there is a definite need for you to label YOUR messages.

We, Japanese, feel NO need. Swedesh, who have two localizations,
ISO 646 variant and ISO-8859-1, might think differently, but it is a problem
of bad localization. Accept the reality of real users.

< 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.

That WAS a start. No one objected to do so from the beginning.

<< 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.

You don't understand the difference between leaf MTA and display (which
may be interpreted as leaf MUA). There capabilities are different.

<< 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.


Sure, we are doing a lot of useful works withut MIME. So? Are you
proposing that we shouldn't have MIE, because we can do a lot of
useful works without it?

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.

The problem of your crystal ball is the range. You can't see what is happening
in Asia nor what will happen 10 years later in the world. Polis it up.

<< 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!


One of the problems is that some do not want to admit that MIME
failed in such a small (for you, but not for me, OK?) part.

                                                Masataka Ohta

<Prev in Thread] Current Thread [Next in Thread>