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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 11 Aug 2009 20:08:54 -0700
Cc: "Daniel R. Tobias" <dan@tobias.name>, uri-review@ietf.org, hybi@ietf.org, uri@w3.org
Message-id: <87FF3009-5686-43ED-9A64-16D41FE27990@apple.com>
To: David Booth <david@dbooth.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/"  
> 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.

Received on Wednesday, 12 August 2009 03:09:59 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:52 UTC