Martin Duerst wrote: > ... > It may or may not need such a special case. The truth is that some years > ago (less than 10), virtually all existing non-ASCII path information > in (U/I)RIs had to be interpreted in the encoding of the containing page. > This has changed, because people started to pick up on the idea of IRIs, > more and more systems used UTF-8 on the server side, and at least some > people understood that using the encoding of the containing page > made it impossible to treat such identifiers free-standing. Also, a > fallback for paths in legacy encodings is still availible (and was always > available): %-encoding. > > As long as query URIs are interpreted based on the encoding of the > containing page, they will stay useless without that context. I.e. > they cannot (without further pain) be put into bookmark lists, they > cannot be sent in email, and so on. The only sensible way to make > this possible is to do the same as for the path part, namely use > UTF-8 for the IRI->URI conversion. Freestanding (U/I)RIs with > query parts may be less important than freestanding (U/I)RIs > without query parts, but still, they are often convenient. > However, they won't work if implemented the way HTML5 is currently > describing them. Also, same as for path parts, a fallback for query > parts in legacy encodings is still availible (and was always > available): %-encoding. > > In summary, there are cases where things changed to the better > in the last few years, and there are cases where some solutions > make the Web work better than others. > ... Note that HTML5 documents that carry aren't encoded in UTF-8 (or UTF-16) and which carry non-ASCII query parameters are currently non-conformant. (I personally don't think it makes a big difference in practice as HTML5 makes normatively defines their handling, so people will rely on that anyway). >> That can be done in a separate spec, defining a mapping from "HTTP URL" to IRI reference, and then letting the default URI/IRI rules apply. > > I'm very much confused by "HTTP URL". In case that's the term that HTML5 > currently uses, it should use a different one, to avoid confusion. Actually, I wanted to say "HTML URL" (URL as used in HTML5). HTML5 really uses just the term "URL". BR, JulianReceived on Tuesday, 8 July 2008 08:04:02 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:19 GMT