Maybe I've been talking to Masataka by e-mail too much and my mind is
becoming corrupt, but I think I can explain what he's saying. I think I can
also explain, clearly, why what he is proposing is impractical and not
terribly useful:
"impractical and not terribly useful"? OK?
Therefore according to Ohta if all you are using is ISO 2022, you (as
either a user or a MUA) don't need MIME to label character sets.
This is trivially true, but awfully boring and pragmatically useless.
"awfully boring and pragmatically useless"? OK.
The
fact is that point 4 is unreasonable: The MIME standard already exists and
is written to accomodate lots of character sets.
I don't mind there are a lot of localizations distinguished by MIME charset
mechanism.
Though it is true that we
could write a version of Eudora that only supported ISO 2022 and didn't
have any MIME headers,
Support whatever characters you locally need.
we would still have to write another version that
*did* support MIME headers because there are lots of MIME mailers out there
and there are people who *do* want to use more than one character set in
their messages. It doesn't help the position to claim that they don't
*have* to use more than one character set. The fact is that they already
do.
Surely, your mind has corrupted. The whole point of ISO 2022 is to support
more than one character set.
So Ohta can try to put the toothpaste back in the tube, but we're not
going to get anywhere down that line.
Where are you going when we are already at the goal? To the start line?
But more importantly, there are good solid reasons for wanting to use
different character sets labeled in MIME instead of ISO 2022 (and Ohta
knows at least the first reason very well; I saw it in a draft of a paper
he wrote):
What illusion have you seen in our draft?
(a) ISO 2022 is computationally a pain compared to having explicit charset
labels. You need context to figure out what the escape sequences mean. Ohta
agrees that 2022 is not the "one-true-way" (though he is loath to say that
here, apparently). It's not clear to me why he doesn't admit that here.
Yes, with ISO 2022, it is a pain to keep context to figure out what
the escape sequences mean. Lost state is actually causing real world
problems.
But, With ISO-2022-JP, with ISO-2022-JP-2 and ISO-2022-INT-*, it's
not a pain. You can always reset context at the beginning of the line.
(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".
MUA? What? Mail message must be handled by wide variety of programs,
most of which does not recognize MIME syntax.
And, to display is the role of terminal emulator.
Then you only have to load up fonts for 8859-1. If you are told
"everything that follows is ISO 2022", lord knows what resources you need.
No, font should be loaded on demand.
It makes the coding job that much harder.
What is "the coding job"? The data is already there encoded.
Given the state of affairs now, it is impractical and silly to recommend to
SUNET that they should not go to MIME.
Agreed. So, I didn't say they should not go to MIME.
At the same time, it is true that, if a single localization is what they
want, they don't have to go to MIME.
Some day, when we have a single
character set that is the "one true way" (which might be something like
UCS-4, according to Ohta) and mail transports that can handle such things,
perhaps we can define "Mime-Version: 2.0" in the headers and say that all
text parts are in that one true character set.
Sorry, but we already need real internaionalization today, so that
we can't wait ISO redo UCS 4 right.
Until then, MIME charset
labels are really the only way to go and SUNET should not be at all
disuaded from doing so.
SUNET may need MIME 8bit, but no MIME charset.
Your opinions are impractical, not terribly useful, awfully boring,
pragmatically useless and silly.
Masataka Ohta