W3C home > Mailing lists > Public > uri@w3.org > August 2009

Re: [Uri-review] ws: and wss: schemes

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
Message-Id: <1249690925.3937.32.camel@dbooth-laptop>
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:
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:13 UTC