- From: David Booth <david@dbooth.org>
- Date: Fri, 07 Aug 2009 20:22:05 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: uri-review@ietf.org, uri@w3.org, hybi@ietf.org
On Fri, 2009-08-07 at 19:40 +0000, Ian Hickson wrote: > On Fri, 7 Aug 2009, David Booth wrote: > > > > This looks to me like a perfect example of a case where a new scheme is > > not needed, as the same thing can be accomplished by defining an http > > URI prefix, as described in "Converting New URI Schemes or URN > > Sub-Schemes to HTTP": > > http://dbooth.org/2006/urn2http/ > > Note that I am talking about the *scheme*, not the protocol. In > > essence, a URI prefix such as "http://wss.example/" can be defined that > > would serve the same purpose as a "wss:" scheme: an agent that > > recognizes this prefix will know to attempt the WSS protocol. But an > > agent that doesn't *might* still be able to fall back to doing something > > useful with the URI if it were an http URI, whereas it couldn't if it > > were a "wss:" URI. > > This is only expected to be used from a WebSocket API call. What fallback > behaviour did you have in mind? I'm sure I could come up with some ideas, but I imagine those who have been working on HTML5 could come up with much better ones. I tried to look in the HTML5 spec for some inspiration, but I find the word "socket" appearing only once, in section 8.1: http://dev.w3.org/html5/spec/Overview.html#event-definitions Where should I look for the info that gives the context for the WebSocket API? OTOH, protocols have a way of finding uses far beyond those for which they were originally envisioned. -- David Booth, Ph.D. Cleveland Clinic (contractor) Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Received on Saturday, 8 August 2009 00:22:43 UTC