- 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