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.
With unwise profiling, that is true.
But, it is not applicable to ISO-2022-INT-*.
For 2022, you would have to
actually interpret the text to see what characters you need and then
display them.
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 problem applies to other character sets as well (e.g.
Unicode), but your comments don't address my argument at all.
Unlike ISO-2022-INT-*, Unicode font, in general, is not available
freely or, even worse with combining characters, undefined.
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.
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.
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.
Mail programs should simply pass 1-127 as is. What a great programming
project.
But, (a) there *are* other representations that
are being used
That's MIME issue. Let charset handle it.
(b) many of them are computationally easier to deal with
that ISO 2022.
You should actually implement something and measre the amount of
computation.
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.
Some people want to write mail programs for X.400. So?
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.
This
will simply cause those people to be unable to interoperate easily with
these other mailers.
So, I just recommend ISO-2022-INT-*.
Once we come up with a character representation that is computationally
easy to deal with across the board and does everything we need,
ISO 2022 is computationally easy to deal with. Things was different
10 years ago.
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.
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).
Masataka Ohta