Re: URL internationalization!

Masataka,

On Wed, 19 Feb 1997, you wrote:

> Yergeau;

I guess he would prefer to be addressed as Mr. Yergeau.


> > >Perhaps, you have never used WWW browsers yet, but, those of us
> > >who have know that we don't need URL human readable unless it
> > >is keyboarded, transcribed or mailed.
> > 
> > Those of us who have long used, and even written, browsers, know that the=
> > y
> > are used very often to submit forms.  We also know that these forms can
> > contain arbitrary characters, for instance when one types one's name.
> 
> You have a very limited experience with forms.

As Francois is one of the architects of Tango, a nice browser,
I guess he has enough experience with forms. Anyway, my proposals
are based on repeated discussions with experts also from other,
major browser and server makers. I guess they also have ample
experience.


> I won't accept your name in Arabic script, Devanagali script,
> Hanzi script nor non-ASCII Latin-1 script, in my forms.
> 
> On the other hand, I do accept names in Kanji script if my form
> is for Japan local.

Very reasonable indeed. But can you explain what this has to
do with my proposal? Hopefully, you are doing some plausibility
tests on the results you get, to exclude the many symbols, the
Greek and Cyrillic characters, the line drawing elements, and
undefined positions, which all could easily be sent using JIS
208. Likewise, in the US, a plausibility test would assure that
no names like *xq7)8_-wFZ enter the database. Obviously, this
is independent of the encoding used for the characters, except
that it's easier to do if the encoding is well defined.


> > We also know that servers
> > have problems dealing with such URLs, because the character encoding
> > outside ASCII is undefined by the current Proposed Standard.
> 
> Using ASCII only is the only reasonable way to handle the
> Internaitonalized forms and is the best default.
> 
> Servers know the internal format of the form and have no difficulty
> to properly decode pure ASCII (maybe with %) URL of localized
> forms.

Please distinguish between the URL and the things that are sent in
protocols. HTTP currently uses the %HH encoding of URLs in the protocol,
and leaves it to the server to decode it. However, in general, the
%HH-encoding is there to encode arbitrary octets in to ASCII-only
canonical URLs, while the protocol uses the raw octets. This is
certainly so in case of FTP.


> > that internationalized, non-ASCII URLs are an
> > unavoidable requirement of a *World Wide* Web,
> 
> As long as the receiver of the form can receive and recognize some
> local scripts, he may allow senders use some localized encoding
> of some local script in the form. Then, % notation of URLs is just fine.

It's fine so far in local contexts with a firmly established
convention of using a single character encoding. It's
absolutely not sufficient in a truely WORLD wide web.
How would you suggest the UN or some similar organization
organize their server, forms, and scripts?



> But, the default charset of internationalized form can't be
> anything other than ASCII.
> 
> Otherwise, the receiver can't recognize the form.

Well, I have shown that there is an alternative.


> > Fran=E7ois Yergeau <[email protected]>
> 
> Could you stop using strange local characters for the international
> discussion?

He writes his name, in a correctly MIME-tagged mail. You can do the
same, neither he nor I will complain. It looks like we are ahead in
internationalization.

Regards,	Martin.