Re: URL internationalization!

Jonathan Rosenne <[email protected]> Sat, 22 Feb 1997 10:25:40 -0500
Newsgroups gmane.ietf.url
Message-ID <[email protected]>
Masataka Ohta wrote:
>> There is no standard for representing Arabic or any other non-Latin
script
>> in English, much less in international ASCII.
>
>It is of course, impossible to represent Arabic language in
>English, because Arabic language and English are different
>languages.
>
>Instead, there are formal and/or informal ways to represent
>English in Latin script, Arabic language in Latin script,
>English in Arabic script or Arabic language in Arabic script.

I doubt there is a useful way to represent Arabic in ASCII. There isn't for
Hebrew, which is a much simpler case.

One method which is being used is character substitution. There are two
ways:
- by keyboard position, i.e. Alef becomes T, Bet becomes C etc., but then
';' '.' and ',' need to be alphabetic characters.
- by sequence, i.e. Bet becomes A, Gimel becomes B etc., but since Hebrew
has 27 letters the Alef must be mapped to a symbol and there is no
agreement to which, and in any case again it would not be recognized as
alphabetic.

Another possibility is transliteration, but there is no agreed scheme at
all, and those proposed often use diacritics so they are not ASCII.

On the internet, we should cater also for the native speaker who does not
even recognize the English letters. He should be able to enter a URL in his
own script, to be transformed by software into an ASCII string. Therefor we
need a formal scheme which must also be reversible, i.e. one to one.

A major disadvantage of 2022 is its statefulness. If the user was to cut
and paste bits and pieces of the URL the software must analize the
situation and insert all those escape sequences. With the proposal, if the
URL is presented as is and the user grabs part of a %HH it is 
1) possible to detect the error by the software 
and 
2) a visible and obvious error.

Jonathan