Re: URL internationalization!

> > We don't use worldwide characters on our international airline tickets.
> 
> The airline reservation systems are extremely old and predate
> most of localization or internationalization support currently
> available on computers.

The airline ticket is the evidence that ASCII is enough for
international multilingual processing.

The older the system is, the better working evidence it is.

> > ASCII-only Latin script is perfectly fine as a formal notation of,
> > say, Japanese. For example, Japanese sentence "Doumo" in ASCII
> > means "Hi" in English.
> 
> A lot of distinctions are lost in many cases when reducing
> things to ASCII.

So is UTF-8 with CJK unification.

> done automatically, it is not a solution to the problem of
> non-ASCII resource names.

There is no problem of non-ASCII resource names.

No one need non-ASCII resource names, unless he must type it in
through his local keyboard, where ASCII is the only common
characters.

> > So, if you don't want to detour, never say "language-tag" when
> > what you need is "script-tag", which is MIME charset.
> 
> Criticising other's use of terminology, and then getting it wrong
> yourself, is not the best way of participating in a discussion.

Language tag is a well defined terminology, unrelated to multiscript
discussion.

> MIME "charset" parameter values don't denote scripts,

Who said "script-tag" denotes a single script only?

I said:

	"script-tag", which is MIME charset.

right?

"script-tag", which is MIME charset, denotes scripts and their encoding.

> they denote
> character encodings. Many "charset"s allow several scripts to be
> encoded (iso-2022-jp for example allows Latin, Greek, Cyrillic,
> and Kanji/Hiragana/Katakana). For many scripts, there are many
> different "charset"s.

That is, iso-2022-jp denote that scripts of Latin, Greek, Cyrillic
and Kanji/Hiragana/Katakana are used with a restricted ISO 2022
encoding and is a script tag.

							Masataka Ohta