It appears that although 10646 is imperfect (some would say sorely
lacking),
it's the best technical solution yet devised.
Do you have any techncal reason to think 10646 is the best technical
solution? I think there is no.
I apologize for being imprecsise. When I said "best technical
solution yet devised", I meant "for a single worldwide character set".
I'm really bored of such nontechnical commercial hype.
If Unicode were a single worldwide character set, so were ISO 646.
Some Japanese use JIS X 0201, an ASCII-incompatible Japanese variation
of ISO 646, with some difficulty in reading ASCII documents. On my terminal,
ASCII backslash is represented by a Yen sign, a currency symbol, which
is not so irretating than seeing CJK unified Han.
Because of C/J/K unification and other reasons such as that there
is no single world wide policy to treat characters of different
languages, it is merely a single PanEuropean character set.
I do really want any technical reason of your opinion. But I don't
think you have techncal bacground for internationalization.
My reasons for believing that 10646 is the best technical solution
yet devised are: (a) 10646 does appear to have been developed by
a great number of experts from all over the world,
A great number of experts for one or two languages! That's the reason
why Unicode is the worst. Most experts never be experts for
internationalization.
Thus, just as ISO 2022, individual part of Unicode was designed
individually by indivudual experts for individual languages.
The result is that, though, unlike ISO 2022, the encoding space is
shared, it is as useless as ISO 2022 for multilingual internationalized
purpose.
and (b) I haven't
seen an alternative that has a similar amount of expertise behind
it. Have you?
Yes, of course. For example ISO 2022 is just only as bad as Unicode while
already accepted in a large market. That's why we, Asian Internet
comminuty, has choosed it as the starting point of Internationalization.
ICODE, as I have presented at Amsterdam IETF and JWCC at Taiwan, has
several desirable features for plain text processing. The features are
shared by ASCII and ICODE while UNICODE, because of a lack of the single
policy, lacks all of them.
Finally, registration of 10646 as a MIME charset is NOT an endorsement of
10646,
So, why you can't register it with profiling?
MIME requires that the character be completely specified by the character set
name. This is so mail mail readers don't have to make complicated decisions
about whether they support a particular character set; they can just
compare character set strings. Given that mail readers have to support
many different kinds of content-types, it still seems like this was
a good engineering decision to minimize the complexity in the mail reader.
So, why you can't register it with profiling?
For 10646 with profiling to fit within the MIME structure, it would
have to be a different content-type. Something like text/iso-10646.
It could then have whatever parameters it wanted to contain the
profiling information.
OK. I'm tired of all the no-discussion. I've writtten an Internet Draft
for ISO 10646.
Let's see. You will be surprized how poorly Japanese Unicode is
supported on Windows/NT.
Masataka Ohta