- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 14 Oct 2011 15:14:38 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
On 2011-10-11 00:30, Ian Hickson wrote: > On Sun, 9 Oct 2011, Arthur Barstow wrote: >> On 10/7/11 8:32 AM, ext Julian Reschke wrote: >>> As far as I recall, we agreed in the IETF WG that parsing of web socket URIs >>> should work exactly the same way as for any other URI scheme. It appears >>> that the API spec now tries to override this, and this looks problematic to >>> me. >> On 10/7/11 9:30 AM, ext Arthur Barstow wrote: >>> In [1], Julian asks about Web Socket API rev 1.247 [2], the change that adds >> the Parsing WebSocket URLs section (CVS comment "Revert the part of r5409 that >> removed the URL parsing algorithms, since it's no longer defined in the >> protocol spec. (whatwg r6632)"). >>> >>> Would you please elaborate on this change? >> >> On 10/7/11 11:28 AM, ext Ian Hickson wrote: >>> Elaborate in what way? >> >> Why is the override in 1.247 needed, given what Julian indicates above? > > There's no override. It's just defining how you do it because nothing else > defines it. As far as I can tell, it's a mix of things repeated from <https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#section-3>, things that may be useful, and things that do not make sense at all. In particular: "Resolve the url string, with the URL character encoding set to UTF-8. [RFC3629]" "Resolve" is undefined as far as I can tell, in particular it's not clear at all what "URL character encoding" means in this context. Best regards, Julian
Received on Friday, 14 October 2011 13:15:25 UTC