Re: URL internationalization!

> > 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.
OK in the minimal TRANSPORT format of an URL. Not in a URL in general.
ASCII can be used to describe words in English. It is not enough for
many other languages. I cannot represent the files on my system with
just ASCII, but I can have a program encode my URLs in ASCII using some
encoding scheme (%HH is defined today). Still, if I encode my iso 8859-1
files with %HH you cannot decode them, if you think it is iso 2022.
We need a transport format that allows non ascii to be transported, while
retaining the meaning of the characters transported. One easy way is to
use a common character set that the local character set is converted to, for
transport. For URLs UCS (ISO 10646) in the UTF-8 byte stream form would
be fine. 8-bit bytes can be encoded using %HH for transport where 8-bits
are not available maintaining an ASCII only version of the URL, which also
can be used at places where all characters cannot be displayd, to make it
possible to enter that URL by a keyboard at those places.

> 
> > In terms of encoding (from characters to octets), chaos is the
> > current state,
> 
> As you said "only ASCII is allowed", there is no chaos.
The chaos is because it is not acceptable for many of us to just
use ascii in our urls, we all use the local character set in our urls.
If the receiver end does not use the same character set, the url will
look like a mess at the receiver.


> 
> As the only internationalization of URLs is ASCII URLs, there
> is no new point.
Internationalisation normally means to allow national characters to be
used. ascii only urls does not allow that (though defining transport
format for an url to be made out of ascii character codes will).


> 
> > 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.
I have never used ISO 2022 and do not want to introduce that chaos that
it is for me.



> 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.

There is NO problem. When my system receives an URL from a place with
Devanagali or from a search engine with characters my system cannot display,
it should display those characters using the %HH encoding of the UTF-8 code
for those characters.
I then have no problem to use them, type them on my keyboard or to write
them on a paper.
The important thing is that if URLs are transported using UTF-8 (with %HH
encodings as needed) my system can know what characts the byte codes in
the URL mean, and display those my system can handle in local format and those
it can not in %HH encodings.
This way URLs can be user friendly, even if they includes non ascii characters.



    Dan Oscarsson