Re: URL internationalization!

Masataka Ohta <[email protected]>
Newsgroups gmane.ietf.url
Message-ID <[email protected]>
Martin;

> In the sense that in the "canonical form" of an URL, only
> ASCII is allowed, my current proposal doesn't change this.

"only ASCII is allowed"? OK.

> In terms of encoding (from characters to octets), chaos is the
> current state,

As you said "only ASCII is allowed", there is no chaos.

> > You have raised no now point.
> 
> No, internationalization of URLs as such is indeed not a new
> point. But proper internationalization of URLs is a new point.

As the only internationalization of URLs is ASCII URLs, there
is no new point.

> In terms of encoding (from characters to octets), chaos is the
> current state, and this is unsatisfactory and can be improved.

ISO 2022 has been the law, dispite all the attempt of you trying
introduce the chaos.

> In terms of how to do it, for about the past year, there have
> been many discussions in particular about UTF-7 or UTF-8.

UTF-* has nothing to do with the internationalization, not even
a localization (outside of Europe).

See RFC 1815 on how to properly do a localization with ISO 10646.

> In terms of keyboarding, the claim that only an extremely limited
> character set would be acceptable was long held up by many
> people. Because it's easy to offer a keyboarding service with
> an HTML page (in particular with a Java applet),

You completely misunderstand the keyboarding problem.

A long-useful proper solution has been to have transliteration
programs from ASCII to local scripts. The solution works for
those who are familiar with the local scripts.

The problem is that, most of, say, French using people does
not know where to find a proper transliteration tool when
they see an Arabic or a Devanagali character and identify
it just a strange graphical symbol of some foreign culture.

No search engines are helpful here to find the keyboarding page,
unless the user can key-in the character.

And, even then, none Greek people can't type in Greek Alpha as
Greek Alpha.

> because it
> is unfair and highly inefficient that local users would have
> to convert their resource names to strange %HH sequences,

Wrong.

It is as easy as rewriting "<" in HTML.

It's easy to offer a translation service with an HTML page (no
Java necessary here).

> Another claim made many times by opponents to URL internationalization
> was that domain names couldn't be internationalized anyway.

No. You understand nothing here.

> With my
> draft-duerst-dns-i18n-00.txt, I showed that it could indeed be done
> very easily.

Can you understand how Russian think what

	ABC.COM

is?

							Masataka Ohta
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.