Re: URL internationalization!

Hello Roy,

On Wed, 19 Feb 1997, you wrote:

> Francois Yergeau writes:
> >Those of us who have long used, and even written, browsers, know that they
> >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.  We
> >also know that upon submission the content of the form is encoded in an
> >URL, in a contraption called the query part.  We also know that servers
> >have problems dealing with such URLs, because the character encoding
> >outside ASCII is undefined by the current Proposed Standard.  Hence we have
> 
> Irrelevant. It is a trivial operation to encode in the URL used in the
> FORM action, or within one or more of the form fields, the character set
> and encoding used by the form or by any individual data field.  Since the
> server controls that data, there is never any ambiguity regarding the
> character set in the subsequent URL.  The only problem that existed,
> and still exists today, is that user agents don't have any understanding
> of the character set, period, and just submit data in whatever octets
> are currently being used for browser display.  That problem has absolutely
> nothing to do with URLs -- it is a general issue of interoperability
> while submitting forms (via URL or message entity) -- and it would not
> be solved by mandating UTF-8 because those old browsers don't use UTF-8.

HTTP uses URLs mostly "as is", and the specs for the HTTP protocol
refer to the URL specs for convenience. It is therefore easy to
relate URLs as such and what is going over HTTP too closely.

Your arguments above may apply for form submission. They are indeed
rather close to what I wrote in my initial mail in this discussion
about form submission. But please notice that URLs, including the
query part, are about more than form submission. Such URLs may get
displayed to the user, they may appear in paper form, and so on.
In these cases, GET with body or POST don't work. Adding a field
to indicate the encoding is likewise very far from being usable,
in particular on paper.


> The difference between writing an Internet standard and inventing an
> ideal world is precisely that interoperability requirements are always
> more important than idle speculation.

I have carefully addressed the interoperability concerns for my proposal.
See Section 4 of my original mail. If you have any more specific questions
or comments, I would be glad to address them, too.

There is nothing wrong in an Internet standard if it tries to advance
and clean up, as long as it doesn't break old practice.


Regards,	Martin.