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:38:34 -0700
Cc: "Daniel R. Tobias" <dan@tobias.name>, uri-review@ietf.org, hybi@ietf.org, uri@w3.org
Message-id: <D48153CE-9167-4227-B630-1F9D1368A686@apple.com>
To: David Booth <david@dbooth.org>

On Aug 11, 2009, at 8:27 PM, David Booth wrote:

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

What hosts would it apply to? One specific one? If it applies to  
exactly one host, then I object to making the scheme rely on a central  
server. We know from experience that this doesn't scale.

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

I would appreciate if you could explain succinctly. Given a URL of the  
form "http://wss.FOO" where FOO represents an arbitrary sequence of  
characters, how to determine whether it should be interpreted as a  
wss: URL instead.

Received on Wednesday, 12 August 2009 03:39:27 UTC

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