[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Call for proposals
Mark;
> This message is mostly addressed to Ohta-san.
>
> Ohta-san, you can rest assured that your position is heard at these meetings.
> I make sure of that, personally, at every meeting which I attend.
You do not.
> I am, however, convinced that an ISO 10646 based solution must have a
> reversible mapping with ISO-2022-JP2. It is obvious that raw Unicode is not
> sufficient for this purpose.
Shut up and listen to me.
My point on this thread is ISO 10646 is universal only with
intra-European scope.
It does not matter whether modified ISO 10646 in the future will
be universal or not.
But, we are moving forward today.
People all around the world have already moved forward with ISO 2022
based encoding without ISO 10646.
> For this reason, I think that the only way to move forward
> is to strike a compromise.
So, no one need compromise.
And, when the question is "to unify or not to unify", what is
"a compromise"?
Is the compromise partially to unify Chinese/Japanese/Korean but
parially not to unify Latin/Greek/Cyrillic?
> And remember:
> ISO 10646 is definitely not the best universal coded character set;
> it's the *only* universal coded character set.
<From the IETF context, what matters is MIME charset, for which
ISO-2022-JP-2 is a universal charset.
> In your paper at Tsukuba, you defined plaintext as "text with finite state
> structure". I'm not convinced that ISO 2022 based solutions, such as your
> proposal (ISO-2022-JP2 or ISO-2022-INT), are any more "finite state" than an
> ISO 10646 based solution
ISO 2022 based solution is better than UTF ones, because the former
is well defined and 7bit.
It is, of course, possible to make UCS4, in the hopefully-not-so-far
future-but-not-now, the real stateless encoding.
> ISO 10646 based solution with "language tags" (I'm putting this term in quotes
> deliberately, see below).
While you might call arbitrary anything "language tags", your
definition on "language tags" has nothing to do with other
definitions of "language tags" including that of RFC 1766.
> I am, however, convinced that an ISO 10646 based solution must have a
> reversible mapping with ISO-2022-JP2. It is obvious that raw Unicode is not
> sufficient for this purpose. "Language tags" is a misnomer; we actually are
> not shifting languages, we are shifting through various alternate glyphs for a
> particular character. Kobayashi-san from Justsystem suggests "source ID",
> although this too many have nomenclature problems.
>
> Let's not bother with what they are called, and for the time being let's call
> them "blurdybloops" instead.
You can simply call it "escape sequences".
Don't reinvent ISO 102022.
Masataka Ohta
PS
ISO 102022 is trade marked by J.C.Klensin. :-)