- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 11 Aug 2009 20:08:54 -0700
- To: David Booth <david@dbooth.org>
- Cc: "Daniel R. Tobias" <dan@tobias.name>, uri-review@ietf.org, hybi@ietf.org, uri@w3.org
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. 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. Finally, I do not think hosting a WebSocket service should require having a host set up with "wss" at the start of the name. 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. Regards, Maciej
Received on Wednesday, 12 August 2009 03:09:59 UTC