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