I will try to stick to issues that Nathaniel has not addressed and talk
about those things to which apply to my messages alone. I have also removed
everyone except for ietf-822 from the recipients.
On 11/16/94 at 11:32 PM, Masataka Ohta wrote:
...what he is proposing is impractical and not terribly useful:
"impractical and not terribly useful"? OK?
Yes. We currently live in a world where different countries use all sorts
of different schemes for encoding characters. In the US and UK, there are
many many people who still use exclusively ASCII. In parts of Europe, the
ISO 8859 representation is used. In Japan, ISO 2022 is used. In some parts
of the world, ISO 646 is used. For you, Ohta-san, to recommend that Sweden
need not implement a standard which supports MIME is impractical. MIME is
able to help mail programmers sort out all of this mess (and it *is* a
mess). If you could show me that the world was on the brink of
understanding that ISO 2022 is the one true way to represent characters and
that soon everybody would be using it, I would say that your proposal was
both practical and useful. Until then, it is a bad proposal.
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.
Let me be clear on what I mean:
"Awfully boring": What you say is true; if you use exclusively ISO 2022,
you would have no need for labeling charsets. But, as with most logical
arguments of this form, if the antecedent is false (i.e. you *can't* say
that you will exclusively use ISO 2022), then the truth of your statement
is trivial. You have not added anything to the argument by going under the
assumption that Sweden can exclusively use ISO 2022; they simply cannot if
they wish to function in this world of too many character set encodings.
Your utopia, regardless of your denials to the contrary, simply does not
exist.
As for "pragmatically useless", I have addressed that above.
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.
But if people *do* use it for localizations, they will end up using it to
send messages outside of their locale, and then being 2022-centric will be
useless.
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.
So, the man who is claiming that it is horrible for us to be Eurocentric is
now telling us that we should become *more* Eurocentric by supporting only
local needs? Sometimes I just don't understand.
Our programmer time is much better spent by writing an application that
will satisfy our Japanese users, US users, Isreali users, and Egyptian
users without having to localize the actual code for each version. (Of
course we have to localize the names of the commands and the menus, but we
don't want to change the code itself for every country.) The best way we
can do that now is to write a single version which uses MIME charset
labeling because 2022 acceptance is *not* universal.
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.
I misspoke. What I meant to say was that "It doesn't help the position to
claim that they don't *have* to use more than one character set encoding."
Again, 2022 is not widespread enough to be able to committ to it.
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?
No. Again you are confusing what would be best with where we are now. Where
we are now is multiple character set encodings and MIME. To say that we
should get rid of it is trying to go back to the starting 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?
The ones you quote immediately:
(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.
I will accept that. However, is your claim that we should all use
2022-INT-* and that it includes all necessary characters? So we can throw
away 2022-JP and JP2 as well? That would be nice.
(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.
Ohta-san, again you have revealed that you are as much of a barbarian as
the rest of us. Just because you are UNIX-centric and
terminal-emulator-centric does not mean that the rest of us are. Some of us
write code on operating systems that are completely graphics based with no
concept of a *terminal* emulator. When we write our mail applications, we
handle the MIME, the display to the user, the character set handling, etc.
We do not have terminal emulators that handle character set transitions in
hardware. We have to load up graphic font resources, display the characters
as necessary, and handle display of everything for the user.
May I assume from this that you are not a programmer? Or perhaps only that
you have programmed only for one environment.
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.
Easier said than done sometimes. And again, fonts are not the only issue.
For the Macintosh, I may need all sorts of script resources to be able to
handle Japanese or Arabic, even if I have the fonts. I would like to know
this before I enter my display routines.
It makes the coding job that much harder.
What is "the coding job"? The data is already there encoded.
A miscommunication: "Coding" is a colloquial word for "programming".
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.
Yes you did! In your original message, you wrote:
You don't need MIME at all.
and:
For the smooth transition, you can even design 7bit mixed encoding of
Swedish variant of ISO 646 and right part of Latin-1, which makes MIME
even more unnecessary.
At the same time, it is true that, if a single localization is what they
want, they don't have to go to MIME.
Are you making the rather thin distinction between telling them that MIME
is unnecessary/unneeded and not telling them that they shouldn't go to
MIME? That is a very very weak distinction indeed!
Your opinions are impractical, not terribly useful, awfully boring,
pragmatically useless and silly.
Perhaps. But unlike you, I think I have made good arguments that your
arguments and claims are not helpful to Sweden's decision to go to MIME
(well, except perhaps to the claim of "silliness"; that may have been
uncalled for). What are your arguments that my claims in these articles
have been non-useful, impractical, or logically boring?
pr
--
Pete Resnick - presnick(_at_)qualcomm(_dot_)com
QUALCOMM Incorporated
Home:(217)337-1905 / Fax: (217)337-1980