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

> 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:

> 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

> 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 UTC

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