I apologize for all of this text, but I feel I must defend my position.
For the record, I have had wonderful and enjoyable conversations with Ohta
by private e-mail and I have agreements with him on lots of points. But in
this forum, Ohta seems to be the agressor, so I feel the need to defend.
On 11/17/94 at 12:26 AM, Masataka Ohta wrote:
Displaying is the job of terminal emulator and has nothing to do with
MUA.
Anyway, displaying is for human beings to read and, with todays computers,
the overhead is unnoticale.
This is extremely close-minded of you. There are some MUA's that *must*
deal with all of the display and the overhead is not at all unnoticable. I
am glad that you use only those systems which such overhead is unimportant;
not all of us are so lucky.
Unlike ISO-2022-INT-*, Unicode font, in general, is not available
freely or, even worse with combining characters, undefined.
Find me a complete ISO-2022-INT-* font for the Macintosh. I'd be glad to
use it as I work on Eudora's display engine. Apple has provided me Unicode
conversion; what have you done for me lately? :-)
It depends. Loading the font for 8859-1 might be quite efficient because it
is so small. Maybe it's not efficient.
I'm afraid that is a very minor point of implementaion.
Perhaps. But again, I think you are being closed-minded with regard to
other platforms.
Remember, we are talking about computation here, not what the user desires.
Sure. So, don't say "inefficient" if the computation time is unnoticable
to the user.
I know you have not programmed on a Macintosh. Don't make claims which you
cannot defend. There are lots of programming problems on graphical based
systems like Macintosh and XWindows which you don't have to worry about if
all of your text handling is dealt with by a terminal emulator.
Mail programs should simply pass 1-127 as is. What a great programming
project.
:-) More close-mindedness. Display can still be a problem.
But, (a) there *are* other representations that
are being used
That's MIME issue. Let charset handle it.
Wait....wait.....now I'm really confused. So you say we *should* use MIME
charset indicators, but that we should only recognize them and only
generate ISO 2022? This argument is getting confusing.
(b) many of them are computationally easier to deal with
that ISO 2022.
You should actually implement something and measre the amount of
computation.
I am trying to. We'll see what happens.
Some people want to write mail programs for X.400. So?
Correct! And we would consider it naive of them to say, "Don't worry about
using TCP/IP; just use native OSI protocols." Sure, I could write a mail
program like that, but it wouldn't interoperate well. In this day and age,
we *must* deal with MIME.
Once that is done, it is silly to recommend that anybody
committ to a mail standard that does not label the character encoding.
So, is it silly to recommend MIME?
What a broken argument.
I am more confused by the minute: If some day we have a single character
set encoding that is used world wide, we will not need to use MIME charset
specifiers at all. Until that time, to say that MIME is unnecessary is
being silly. Why is this argument "broken"?
Once we thought that ASCII was all
that was needed and all we needed was to define RFC 822. That's obviously
not true anymore,
What?
RFC 822 is good enough for multilingual processing.
No, RFC 822 can only handle multilingual processing if:
1. You have a terminal emulator or mail program that can handle ISO 2022
*and* all of your mail uses that standard.
or:
2. You use MIME.
but ISO 2022 is not the perfect answer to the question.
It's the best answer available today (and in the future for more than 10
years, I'm araid).
Perhaps it is. But that *doesn't* mean (and I will repeat this over and
over) that you should then tell Sweden that they don't need to use MIME.
That's what you said, and that is unrealistic.
You keep missing the point of the argument.
pr
--
Pete Resnick - presnick(_at_)qualcomm(_dot_)com
QUALCOMM Incorporated
Home:(217)337-1905 / Fax: (217)337-1980