Re: URL internationalization!

Francois Yergeau <[email protected]>
Newsgroups gmane.ietf.url
Message-ID <[email protected]>
À 08:25 19-02-97 -0800, Roy T. Fielding a écrit :
>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.

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

Spare me the self-sufficient, derogatory language.  Are you so short on
real arguments that you need to resort to what amounts to an ad hominem
attack?

This one is particularly ironic after you implicitly recommend what is no
more than a dirty hack to solve a long-standing interoperability problem,
instead of fixing the spec that creates it. The meaning of non-ASCII octets
is unspecified by RFC 1738 and its successor-to-be (your draft), and the
best you can come up with is to solve that by advising each and every form
author to place a marker in each form so that the server can *guess* the
encoding?  A kludge.  A crutch for an incomplete specification.  Let's talk
about rigour in Internet protocols, instead of idly speculating about idle
speculation.

>The transcribability requiremenst of URLs are not roundly ignored in
>current practice

The purported transcribability requirements are ignored everything time
someone types a non-ASCII character in a form and submits it.  Or it is
not, if the browser %-encodes those taboo 8-bit bytes; that works just as
well with UTF-8.

>If you obey the restrictions in the URL spec,
>you are guaranteed interoperability with all WWW systems.

Which is why there is a spec, of course.  However that spec needs amendment
to play its role when non-ASCII characters are involved, so that people do
not have to constantly re-invent ugly kludges to circumvent its shortcomings.

>  If you don't,
>then you are not guaranteed to make it as far as a network request before
>your application software pukes, rolls-over, and dies.

Nice rethoric.  You are not addressing the problem, just totally ignoring it.


-- 
François Yergeau <[email protected]>
Alis Technologies Inc., Montréal
Tél : +1 (514) 747-2547
Fax : +1 (514) 747-2561
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.