- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 15 Jun 2012 16:15:53 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: Adam Barth <w3c@adambarth.com>, Michaelâ„¢ Smith <mike@w3.org>, www-archive <www-archive@w3.org>
On 2012-06-15 15:57, Anne van Kesteren wrote: > On Fri, Jun 15, 2012 at 3:49 PM, Julian Reschke <julian.reschke@gmx.de> wrote: >> That discussion went nowhere, as far as I recall. In particular it was >> claimed that something webkit does is needed for web compatibility but then >> we heard that mozilla disagreed (I think it was the special treatment of "\" >> outside file: URIs). > > That was by far not all of it. Indeed, but we certainly failed to come up with a usable list of things that need to be addressed. >> What would be helpful is a clear problem statement. Like "the RFCs force us >> to handle this URI in a way that is incompatible with existing content". I'm >> sure there *are* problems, but simply writing down what webkit happens to do >> today (*) makes it incredibly hard to see what the difference is. > > I gave you an example already. Something that came up recently at That was an example for a case where you're looking for a error recovery strategy. The RFCs do not contain this. This doesn't mean they are incorrect, it just means that the layer they describe doesn't care. > Opera is whether a raw "\" in the query component needs to be escaped. That's an interesting question, but again it's solely about error recovery ("\" is invalid in URIs). > More than two slashes following an hierarchical scheme is another. As > I and others explained before, the RFCs leave a lot up to > implementations and that does not match what we need. We could try to > write something on top of those RFCs, but so far nobody has been > successful at that. Well, maybe it's worth trying. The other strategies that have been tried haven't resulted in a finished spec, either, right? Best regards, Julian
Received on Friday, 15 June 2012 14:16:32 UTC