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

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

From: David Booth <david@dbooth.org>
Date: Tue, 11 Aug 2009 23:27:38 -0400
To: Maciej Stachowiak <mjs@apple.com>
Cc: "Daniel R. Tobias" <dan@tobias.name>, uri-review@ietf.org, hybi@ietf.org, uri@w3.org
Message-Id: <1250047659.3990.1971.camel@dbooth-laptop>
On Tue, 2009-08-11 at 20:08 -0700, Maciej Stachowiak wrote:
> On Aug 11, 2009, at 7:52 PM, David Booth wrote:
> 
> > On Tue, 2009-08-11 at 17:23 -0700, Maciej Stachowiak wrote:
> >> On Aug 9, 2009, at 6:52 PM, David Booth wrote:
> >>
> >>>
> >>> I can't see that as a significant issue, as there is only a trivial
> >>> difference between dispatching based on the string prefix
> >>> "http://wss.example/" and the string prefix "wss:".  Both are  
> >>> simple,
> >>> constant strings and both are equally "magic": they cause agent to
> >>> attempt the WSS protocol.
> >>
> >> The difference is that "http://wss.example/" already has a meaning,
> >> which is not the intended one. Whereas "wss:" currently has no
> >> meaning. Thus the former has greater risk of either colliding with an
> >> existing resource, or being misinterpreted by a legacy client  
> >> (instead
> >> of just rejected).
> >
> > That's not a risk, that's the *intent*.  The point is that a prefix  
> > like
> > "http://wss.example/" gives agents that do not know the WSS protocol  
> > the
> > possibility of doing something useful with the URI, by falling back to
> > the HTTP protocol, whereas if a prefix like "wss:" were used those  
> > same
> > agents would have to reject it entirely.  The "http://wss.example/"  
> > URI
> > still retains its meaning as an http URI, but it gains *additional*
> > meaning as a WSS URI for those agents that know how to handle the WSS
> > protocol.
> 
> I do not believe it is an advantage for new clients to retroactively  
> reinterpret existing http resources as wss resources. There exist  
> hosts whose name starts with "wss", so this seems inevitable. This  
> seems like a clear disadvantage.

You've misunderstood.  This would not apply to arbitrary hosts whose
name starts with "wss".  Please re-read
http://dbooth.org/2006/urn2http/

> 
> I also do not believe it is an advantage for legacy clients to  
> dereference wss: hosts via http; it hypothetically sounds neat but I  
> cannot think of a use case where it would actually be beneficial. This  
> is not necessarily a disadvantage, but it doesn't seem like much of an  
> advantage either.

Jamie Lokier just gave one:
http://lists.w3.org/Archives/Public/uri/2009Aug/0011.html

> 
> Finally, I do not think hosting a WebSocket service should require  
> having a host set up with "wss" at the start of the name. 

It wouldn't.  You've misunderstood.  Please re-read
http://dbooth.org/2006/urn2http/

> Parties  
> deploying WebSocket services may be in control of their own DNS  
> namespace, so this is an onerous requirement. That seems like a clear  
> disadvantage of your scheme.
> 
> In conclusion, I think your proposal is idiosyncratic, and not a good  
> fit for the WebSocket protocol.



-- 
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 Wednesday, 12 August 2009 03:28:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:42 GMT