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

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

From: David Orchard <orchard@pacificspirit.com>
Date: Tue, 11 Aug 2009 20:46:34 -0700
Message-ID: <2d509b1b0908112046m47475950j3a8852e052a95f2a@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: David Booth <david@dbooth.org>, "Daniel R. Tobias" <dan@tobias.name>, uri-review@ietf.org, hybi@ietf.org, uri@w3.org
Please look at the recent XRI specs.  They were successfully convinced
to use http: URI scheme rather than inventing a new xri: scheme, and
their spec is much the better for it.


On Tue, Aug 11, 2009 at 8:38 PM, Maciej Stachowiak<mjs@apple.com> wrote:
> 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.
> Regards,
> Maciej
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
Received on Wednesday, 12 August 2009 03:47:17 UTC

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