- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 23 Oct 2012 11:19:16 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: uri@w3.org
On 2012-10-23 11:09, Anne van Kesteren wrote: > On Tue, Oct 23, 2012 at 11:45 AM, Julian Reschke <julian.reschke@gmx.de> wrote: >> On 2012-10-23 10:36, Anne van Kesteren wrote: >>> * Building on top of STD 66 is not practical. You want a single >>> algorithm that deals with parsing, resolving, and canonicalizing. >> >> Sounds like three algorithms with well-defined interfaces to me. > > Feel free to take mine, do that, and convince people it's better. It's > in the public domain. I have not done it as it just results in > overhead and no benefit. > > >> What's "common usage" may depend on context. It may be true for the browser >> world. > > http://www.googlefight.com/index.php?word1=url&word2=uri I was referring to "whatever you find in @href" as opposed to "what RFC 3986 says it is". >>> * For Julian, an example of a URL that would be invalid per STD 66 yet >>> is transmitted over the wire just fine: http://www.w3.org/% or >>> http://www.w3.org/?% Also fragments such as #™ do not undergo any >>> transformation. Fragments are pretty much parsed as literals except >>> for thirty or so code points. >> >> Again, I'm mainly interested in *valid* URIs where you think RFC 3986 needs >> fixing. > > This was about demonstrating that STD 66 is not a suitable interface. > (I thought you suggested that. If not, sorry, hopefully it helps > someone else.) OK, so if browsers put /% on the wire *and* servers rely on that, that would be an issue. However, I'm not convinced the latter is the case. Best regards, Julian
Received on Tuesday, 23 October 2012 09:20:17 UTC