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