- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 07 Sep 2009 15:47:26 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: URI <uri@w3.org>, "hybi@ietf.org" <hybi@ietf.org>, "uri-review@ietf.org" <uri-review@ietf.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Ian Hickson wrote: > ... >>>> Furthermore, it still doesn't answer what the semantics of these >>>> parts are. What do "ihier-part" and "iquery" represent in a ws URI? >>> This is defined by the RFC 3987, no? Surely we wouldn't want IRI >>> components to have different meanings in different schemes? >> If you can point to a section in RFC 3987 which defines more than the >> syntax, and can state that that also applies to "ws", then, great... > > Isn't what the Web Socket protocol spec now says suitable? > ... It's better. What I still miss is a reference from the URI registration template to the section which defines the syntax (*), and in that section, a statement about what the resource name exactly is good for. (It's definitively not obvious by just reading the parsing algorithm). BR, Julian (*) I think that section would be much more readable when it used ABNF as everybody else does. I hear that by specifying an algorithm you want to exclude certain standard things like fragments, and include error handling; but I think ABNF + prose would be much easier to understand. Furthermore, fragment identifiers are orthogonal to the URI scheme, see <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.2>: "Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications."
Received on Monday, 7 September 2009 13:48:09 UTC