- From: David Orchard <orchard@pacificspirit.com>
- Date: Tue, 11 Aug 2009 20:46:34 -0700
- 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. Dave 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