RE: [Uri-review] ws: and wss: schemes

On Fri, 7 Aug 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > The formal registrations for the ws: and wss: schemes, part of the Web
> > Socket protocol, will be available in the Web Socket protocol ID as soon as
> > the IETF upload process completes:
> > 
> >    http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol#section-7
> 
> Looking at:
> 
> > 7.1. Registrarion of ws: scheme
> > 
> >    URI scheme name.
> >       ws
> > 
> >    Status.
> >       Permanent.
> > 
> >    URI scheme syntax.
> >       "ws" ":" hier-part [ "?" query ]
> 
> I assume you are using ABNF syntax (RFC5234) and terminology from the URI
> spec, but you really need to state that.

Thanks, fixed.

(I tried referencing STD68 instead of RFC5234, as we do in HTML5, but 
apparently there's no index of STD references for xml2rfc?)


> >    URI scheme semantics.
> >       The only operation for this scheme is to open a connection using
> >       the Web Socket protocol.
> > 
> >    Encoding considerations.
> >       UTF-8 only.
> 
> What does this mean?

That the only encoding that can be used with this scheme is UTF-8. What is 
unclear?


> >    Applications/protocols that use this URI scheme name.
> >       Web Socket protocol.
> > 
> >    Interoperability considerations.
> >       None.
> > 
> >    Security considerations.
> >       See "Security considerations" section above.
> > 
> >    Contact.
> >       Ian Hickson <ian@hixie.ch>
> > 
> >    Author/Change controller.
> >       Ian Hickson <ian@hixie.ch>
> > ...
> 
> I believe that for a permanent registry on the standards track, change control
> will have to move to IETF or IESG.

When a registration is placed on the permanent registry, the change 
controller line is removed.


On Fri, 7 Aug 2009, Julian Reschke wrote:
> 
> Furthermore I see no mention at all of these URI schemes in the 
> remainder of the spec. So is the IANA registration template supposed to 
> *be* the definition?

Yes.


> In particular:
> 
> 1) What does a "ws" URI identify?

I have added text speaking to this.


> 2) What is the semantics of "hier-part" and "query"?

I've refactored the Web Sockets API and Web Sockets Protocol specs so that 
the parsing of Web Socket URLs happens all within the Web Sockets Protocol 
spec. Let me know if that's not enough. I can include more details if you 
would like.

(If you do want more, a reference to how another scheme registration 
defines the semantics of parts of the URL would be useful, so that I can 
use a similar style.)


On Fri, 7 Aug 2009, Greg Wilkins wrote:
> 
> Note also that ws is commonly used to denote Web Service.
> For example:
> 
>   http://www.w3.org/TR/ws-arch/
>   http://www.w3.org/TR/ws-i18n/
>   http://ws.apache.org/
>   http://www.ws-i.org/
>   https://jax-ws.dev.java.net/
> 
> While you will never avoid all name clashes, it would be desirable to 
> avoid a clash within the same field of endeavour.
> 
> Perhaps wskt would be a better scheme name for WebSocKeT, unless here 
> are any objections from Wichita Southeast Kansas Transit Inc 
> http://acronyms.thefreedictionary.com/Wichita+Southeast+Kansas+Transit+Inc. 
> (note wsock is already used for winSock drivers).

On Fri, 7 Aug 2009, Maciej Stachowiak wrote:
> 
> I think it's unlikely the "ws" family of formats and protocols will want 
> to register their own URI scheme. That being said, how about "wsp" for 
> WebSocket Protocol?

On Fri, 7 Aug 2009, Chris Anderson wrote:
> 
> As long as we are throwing out acronyms, my suggestion would be for the 
> simple "websocket" or maybe "websock" if bytes are considered expensive. 
> I'm a big fan of the mailto: link b/c it's easy to understand what it 
> means.

On Sun, 9 Aug 2009, Mark Nottingham wrote:
>
> websock seems like a good balance...

On Sun, 9 Aug 2009, Pieter Hintjens wrote:
> 
> 'ws' is confusing to many and cryptic to the rest.  'websock' has the 
> advantage of immediate clarity to all.  The 5-characters difference is 
> not worth the cost of defining a new abbreviation that adds no value.
> 
> Think of this as an opportunity for marketing.  "websock" reinforces the 
> brand, while "ws" weakens it.

I haven't changed the names of the schemes.

"wskt" looks really ugly. "wskts" sounds like a plural.

"wsp" and "wsps" don't seem to reduce the confusion with Web Services, 
should they ever add a protocol (and the closeness to "wasp" is not 
especially good, IMHO).

"websock" and "wsock" are too close to the Windows Sockets names, IMHO.

I'm not really concerned about branding; I mean, 90% of the time these 
URLs are going to be seen in contexts like:

   var socket = new WebSocket('ws://example.com/');

...so it doesn't seem like much of an issue.


On Fri, 7 Aug 2009, David Booth wrote:
> > 
> > This is only expected to be used from a WebSocket API call. What 
> > fallback behaviour did you have in mind?
> 
> I'm sure I could come up with some ideas, but I imagine those who have 
> been working on HTML5 could come up with much better ones.  I tried to 
> look in the HTML5 spec for some inspiration, but I find the word 
> "socket" appearing only once, in section 8.1: 
> http://dev.w3.org/html5/spec/Overview.html#event-definitions Where 
> should I look for the info that gives the context for the WebSocket API?  
> OTOH, protocols have a way of finding uses far beyond those for which 
> they were originally envisioned.

The Web Socket API is here:

   http://dev.w3.org/html5/websockets/

I don't really see any sane way to have the API itself do some sort of 
fallback, especially not to HTTP.


On Sat, 8 Aug 2009, Jamie Lokier wrote:
> 
> Tunnelling WebSocket two-way communications over standard HTTP messages, 
> using any of the methods used for that, would be natural and probably 
> useful behaviour.

That is a radically different system on the server-side. While authors 
should naturally be allowed to do that using XHR if they desire, forcing 
servers into having that kind of fallback behaviour radically increases 
the complexity of a server-side deployment. A Web Socket protocol 
implementation can be written in 100 lines of Perl or so; having to add to 
that some sort of HTTP server or CGI scripting would make things 
significantly more complicated.


On Sun, 9 Aug 2009, Julian Reschke wrote:
> 
> Are you saying the URI scheme is *only* needed within WebSocket's API? 
> Why do you need a URI scheme in the first place, then?

It would also be useful when redirecting connections to other servers, if 
we keep that feature, and in general for identifying Web Socket servers 
going forward. For example, we are considering using the Web Socket 
protocol for push notifications; this would need to be declared in an HTML 
page, say in a <link> header, for which having to separately specify the 
host, port, and resource name would be quite inconvenient.


On Sun, 9 Aug 2009, 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.

I don't understand how one would reuse the http: scheme in this way in 
order to connect to 'example.com' as both an HTTP server and a Web Socket 
server.


On Tue, 11 Aug 2009, Maciej Stachowiak wrote:
> 
> 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).

Indeed.


On Tue, 11 Aug 2009, David Booth wrote:
> 
> That's not a risk, that's the *intent*.

I disagree that that is a desireable result in this instance.

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

UAs that don't support Web Socket are going to have failed long before 
they see the URI, since they don't support the API either.


On Wed, 12 Aug 2009 noah_mendelsohn@us.ibm.com wrote:
> 
> So, here's an example.  First, let's make the assumption that there is 
> an HTTP server at port 80 at "http://wss.example/", presumably run by an 
> organization that supports the use of wss.  Assuming that the normal 
> path through the Web sockets client apis does not access this, the HTTP 
> server will be used only by legacy clients.
> 
> Where's the value?  Let's assume that a link to a WS resource winds up 
> in a page somewhere for some reason.  It could be a bug report, 
> whatever. Now a search engine crawler stumbles on the bug report page.  
> If we use the wss: scheme, then either the crawler has special knowledge 
> of WS, or nothing much useful happens.  If we use 
> "http://wss.example/..... then the crawler sends a GET to that.  Choose 
> your favorite metadata access mechanism (perhaps [1], maybe RDFa, 
> whatever), and the crawler has the opportunity to discover "ah, this is 
> a WS resource", or at least to learn some things about it.  To some 
> extent that's true with either approach (the crawler at least knows it's 
> got a link in a scheme that's not understood with wss:), but the 
> opportunities for incremental discovery seem to be significantly greater 
> with HTTP.
> 
> As Dave Orchard points out, these issues were debated in great detail 
> with XRI came up for consideration at Oasis, and I think it's fair to 
> say that the starting position of those proposing xri was initially at 
> least as firm as that of advocates of wss.  I think Dave is right that 
> at least many of those same people came to believe that an http-based 
> approach was in fact either better, or at least a reasonable compromise.  
> You might want to check with them.

Do you believe that the above applies to Web Socket protocol connections 
more than it does to telnet or SSH connections? If so, why?

I don't understand why we would even want a spider to attempt to connect 
to a Web Socket server. How would it know what application-level protocol 
to use? How would it expose this information to the user?


On Wed, 12 Aug 2009, Greg Wilkins wrote:
> 
> The ws protocol has been designed in respect to a single proposed 
> javascript API to run within a browser.
> 
> There are many many uses for bidirectional web which go beyond that 
> simple restricted example.

For those purposes, we already have TCP/IP, no?


On Wed, 12 Aug 2009, Jamie Lokier wrote:
>
> ws:// URLs *will* be entered on web forms at some point, you can count 
> on it.
> 
> Someone will write a web form that says something like "Tell me the 
> address of a FOOCHAT server to begin your FOOCHAT session", expecting a 
> ws:// URL to be entered if WebSockets is the protocol to be used.

Indeed, that's a good reason for having a single URL rather than having 
multiple fields in the API.


Once the IETF system updates to the latest submission, the changes I have 
made in response to the above feedback will be visible in version 32 or 
later of the following document:

   http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 14 August 2009 07:16:22 UTC