Re: URL internationalization!

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

Do you mean Hebrew language or script?

If it's Hebrew language, all the proper nouns in many Christianity
bibles can be written only in Hebrew script. Is it your point?

Or, if it's Hebrew script, it's pointless because this is not a discussion
of transformation between two script. There does exist ways to represent
Hebrew language in ASCII as you can see in Christianity bibles.

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

So, you think the spelling difference between GB and US should
be unified. Great! Good luck.

> A major disadvantage of 2022 is its statefulness.

Can you say bidirectionality?

Could you please explain how you can process Arabic or Hebrew
script with ISO 10646 without being stateful?

I know how to treat such script statelessly. But, ISO 10646 can't
and is not internationalized.

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

It's a problem of user interface side, mostly unrelated to
URL syntax.

But, with pure ASCII URL, there is no "state" problems.

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

Sure. Thus, the encoding should be ISO 2022 based and %HH notation
must be mandatory, which is my proposal.

							Masataka Ohta