On 11/16/94 at 7:26 PM, Kenichi Handa wrote:
It seems that you don't know what ISO2022 is. It is a
method of encoding MANY character sets.
It seems that you don't read what you just quoted from my message:
presnick(_at_)qualcomm(_dot_)com (Pete Resnick) writes:
3. ISO 2022 contains all of the different kinds of characters that you (as
a user) want to use, whatever character set you are interested in, so ISO
2022 is all you really need.
I know quite well (as I stated) that 2022 can and does contain many
character sets. This was not a point that I was arguing against. As a
matter of fact, I claimed that this point was what Ohta had *correctly*
stated. My complaints about 2022 were not that it couldn't represent all
characters necessary for e-mail, but that it was not the *best* way to do
so. The reasons for that are that it is both computational more intensive
and can in some circumstances make for very inefficient use of resources.
(b) The resource load on an MUA to display different glyphs is a great deal
lighter if you have a label which says "everything to follow is in ISO
8859-1". Then you only have to load up fonts for 8859-1. If you are told
If you don't have ISO8859-1 font, what you'll do. Don't
display anything? Perhaps no. You'll try to display at
least ASCII correctly.
True. But the same holds true for 2022 as well. I don't see how this
responds to the argument I was making at all: When you *can* load the font
for efficiency purposes, it might be OK to do so in the case of 8859-1
where there are less than 255 characters. For 2022, you would have to
actually interpret the text to see what characters you need and then
display them. This problem applies to other character sets as well (e.g.
Unicode), but your comments don't address my argument at all.
Even if you have ISO8859-1 font, it
not wise to load ISO8859-1 font before you really encounter
ISO8859-1 chars because there's a possibility of the text
not including any ISO8859-1 chars.
It depends. Loading the font for 8859-1 might be quite efficient because it
is so small. Maybe it's not efficient. But when you have a specific charset
identifier, the MIME part of your program can use it to determine the
limits of what characters can be in that part. Your MIME code can be
seperate from your character rendering code.
Remember, we are talking about computation here, not what the user desires.
All that the user wants is to see what characters the sender typed; to do
that we could use 2022, 8859-x, Unicode, or EBCIDIC for that matter and the
user wouldn't care so long as they could see it. But this has nothing to do
with whether a mail *program* should use MIME or not. Yes, for some aspects
of the programming project, it might be simpler to write a mail program
based entirely on ISO 2022 and not worry about converting other types of
character representations. But, (a) there *are* other representations that
are being used and (b) many of them are computationally easier to deal with
that ISO 2022.
Then, how labeling helps you?
Again, you have ignored the what I said. Of course, there are many cases
where labeling won't help you; if you use solely ISO 2022 and your mail
program knows that and knows how to interpret it, you don't need labels. If
your mail program cannot display characters from certain character sets, a
label does not help you at all. But if you decide, as the folks who wrote
the MIME spec did, that some people who write mail programs will want to
use simpler methods of representing characters than ISO 2022, the mail
message must contain some information indicate which representation you are
using.
Again, do not misunderstand me: It is absolutely true that ISO 2022 can
handle many (if not all) of the characters defined in all of the character
sets currently allowable in MIME messages. That is not the point. The point
is that 2022 has its own problems (contextual representations of
characters, etc.) and that some people want to write mail programs that do
*not* use 2022. Once that is done, it is silly to recommend that anybody
committ to a mail standard that does not label the character encoding. This
will simply cause those people to be unable to interoperate easily with
these other mailers.
Once we come up with a character representation that is computationally
easy to deal with across the board and does everything we need, we can
start talking about a mail standard that everyone must conform to and we
won't need charset labelling anymore. 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, but ISO 2022 is not the perfect answer to the question.
pr
--
Pete Resnick - presnick(_at_)qualcomm(_dot_)com
QUALCOMM Incorporated
Home:(217)337-1905 / Fax: (217)337-1980