On Mon, 12 Dec 1994, Masataka Ohta wrote:
I think this is the heart of your misunderstanding, Ohta-san. You're
thinking about "localizations". In a sense, you're right that you don't
need MIME if you only have "a single localization", whatever that means.
The whole point of MIME's character set facilities, however, was not
"localization" but "globalization" -- making email intelligible
everywhere, regardless of geographic or linguistic issues.
The heart of your misundersntanding is, it seems to me, that multiple
localizations is the globalization. It is not.
Oh, for God's sake, we are going around in circles yet again!
People, Masataka has some very precise definitions of what localization,
globalization, internationalization, etc, mean and how they interact, that
he has developed after years of dealing with these issues in Asia. So
let's avoid using them, shall we? Or we run the risk of further
misunderstanding his definitions and compound the problem even more.
But those definitions have nothing whatsoever to do with the question.
The question is this, and always has been this:
Is there a way to send an e-mail or news message such that the
chances of it being understood and processed correctly by the
recipient are maximised, regardless of what method may have
been used to represent the characters in the message, and
regardless of what political charset axe the sender may have
to grind?
The answer is MIME, always has been MIME, and will continue to be MIME
for the forseeable future.
ISO-2022 conventions have the possibility of taking over some of the
character labelling operations that MIME makes possible, and it also adds
some new operations that MIME is currently poor at (i.e. using lots of
different languages at once in the one body part). However, the chances
of the entire world being able to send ISO-2022 within our lifetimes are nil,
nada, zero, zip, no matter how attractive that goal may be (and it _is_
attractive). It is however possible that being able to display ISO-2022
in MUA's may become universal soon, but we need a label from the sender to
tell the MUA that the ISO-2022 display code should be used instead of
something else.
Give it a rest! ISO-2022 may be nifty, but it is not going to happen
universally no matter how much we may want it to.
I put it to you Masataka: answer the following questions once and for all
(only Yes/No answers need apply):
Is the MIME charset convention an appropriate method for labelling
the encoding conventions used in an Internet e-mail or news message?
Is the MIME charset convention an appropriate method for
disambiguating the use of ISO-2022 from the use of other non
ISO-2022 encodings, should someone wish to use those other
encodings instead of ISO-2022?
Should the MIME charset convention be encouraged to label the
use of ISO-2022 regardless of how "good" or "bad" doing so
may be in the ideal universe?
Note the use of "_an_ appropriate method". Not "_the_ appropriate method".
Maybe if you answer those questions with some firm Yes's or No's, we can
move the MIME standardisation process forward instead of backwards into
infinite bickering back and forth.
I'll go have a cup of coffee now ... :-(
Cheers,
Rhys.
--
Rhys Weatherley, Queensland University of Technology, Brisbane, Australia.
E-mail: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au "net.maturity is knowing
when NOT to followup"