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

From: Ian Hickson <[email-masked]>
Date: Fri, 7 Aug 2009 05:35:16 +0000 (UTC)

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

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 Aug 2009 08:01:34 +0200

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.

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

>    Applications/protocols that use this URI scheme name.
>       Web Socket protocol.
> 
>    Interoperability considerations.
>       None.
> 
>    Security considerations.
>       See "Security considerations" section above.
> 
>    Contact.
>       Ian Hickson <[email-masked]>
> 
>    Author/Change controller.
>       Ian Hickson <[email-masked]>
> ...

I believe that for a permanent registry on the standards track, change 
control will have to move to IETF or IESG.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 Aug 2009 09:04:10 +0200

> URI spec, but you really need to state that.

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?

In particular:

1) What does a "ws" URI identify?

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

BR, Julian

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 07 Aug 2009 18:22:59 +1000

> 1) What does a "ws" URI identify?

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

regards

---

From: David Booth <[email-masked]>
Date: Fri, 07 Aug 2009 09:16:47 -0400

>    http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol#section-7

This looks to me like a perfect example of a case where a new scheme is
not needed, as the same thing can be accomplished by defining an http
URI prefix, as described in "Converting New URI Schemes or URN
Sub-Schemes to HTTP":
http://dbooth.org/2006/urn2http/
Note that I am talking about the *scheme*, not the protocol.  In
essence, a URI prefix such as "http://wss.example/" can be defined that
would serve the same purpose as a "wss:" scheme: an agent that
recognizes this prefix will know to attempt the WSS protocol.  But an
agent that doesn't *might* still be able to fall back to doing something
useful with the URI if it were an http URI, whereas it couldn't if it
were a "wss:" URI.

New schemes should not be created unless they are needed.  I think it
would be better to first implement this by defining an http URI prefix,
see what the adoption is, and then in a few years, *if* there is
widespread agent support for the protocol, then a new scheme may be
justified.

-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

---

From: Ian Hickson <[email-masked]>
Date: Fri, 7 Aug 2009 19:40:24 +0000 (UTC)

> useful with the URI if it were an http URI, whereas it couldn't if it

This is only expected to be used from a WebSocket API call. What fallback 
behaviour did you have in mind?

---

From: David Booth <[email-masked]>
Date: Fri, 07 Aug 2009 20:22:05 -0400

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

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Fri, 07 Aug 2009 21:30:37 -0400

On 7 Aug 2009 at 9:16, David Booth wrote:

> recognizes this prefix will know to attempt the WSS protocol.

It seems like a bad idea to me, to have to build special exceptions 
to how a user agent processes URIs, where the protocol specified in 
the URI isn't actually the one that is used, based on "magic strings" 
within other parts than the scheme.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 07 Aug 2009 15:14:44 -0700

> Note also that ws is commonly used to denote Web Service.

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?

  - Maciej

---

From: Chris Anderson <[email-masked]>
Date: Fri, 7 Aug 2009 15:52:52 -0700

On Fri, Aug 7, 2009 at 3:14 PM, Maciej Stachowiak<[email-masked]> 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?

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.

Cheers,
Chris

-- 
Chris Anderson
http://jchrisa.net
http://couch.io

---

From: Julian Reschke <[email-masked]>
Date: Sun, 09 Aug 2009 09:58:10 +0200

> behaviour did you have in mind?

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?

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 9 Aug 2009 06:50:54 +1200

My .02 -

websock seems like a good balance...

On 08/08/2009, at 10:52 AM, Chris Anderson wrote:

>> want to

--
Mark Nottingham     http://www.mnot.net/

---

From: Pieter Hintjens <[email-masked]>
Date: Sun, 9 Aug 2009 00:00:23 +0200

> websock seems like a good balance...

Apologies for the cross-list posting.  I have to vote with Chris on this.

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

-Pieter Hintjens

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 8 Aug 2009 23:34:14 +0100

> behaviour did you have in mind?

Tunnelling WebSocket two-way communications over standard HTTP
messages, using any of the methods used for that, would be natural and
probably useful behaviour.

-- Jamie

---

From: David Booth <[email-masked]>
Date: Sun, 09 Aug 2009 21:52:02 -0400

> within other parts than the scheme.

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.

---

From: David Booth <[email-masked]>
Date: Sun, 09 Aug 2009 22:05:12 -0400

> probably useful behaviour.

Sounds like a good idea to me, and an excellent reason to use an http
prefix instead of a new scheme.

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Sun, 09 Aug 2009 22:24:21 -0400

> attempt the WSS protocol.

Except that the standards actually provide for the prefix portion to 
indicate particular protocols, while the other parts don't.  That 
doesn't seem trivial to me.  I don't understand the constant pressure 
to dumb down URIs by trying to make everything HTTP.

---

From: David Booth <[email-masked]>
Date: Mon, 10 Aug 2009 13:54:27 -0400

On Sun, 2009-08-09 at 22:24 -0400, Daniel R. Tobias wrote:
> doesn't seem trivial to me.  

But it is the WSS standard itself that defines the WSS protocol, and
that would be the same whether or not the dispatching prefix were
defined to be "wss:" or "http://wss.example/".   

(And just to be clear, I am using "http://wss.example/" merely as an
example http URI prefix.  The actual prefix should be a real domain
name, so that it could provide some useful functionality in the event
that the agent didn't know the WSS protocol. )

> I don't understand the constant pressure 

I don't think "dumbing down" is quite accurate.  The intent is not to
give up any functionality, but rather to achieve the desired
functionality of the new protocol by layering on top of the http scheme,
rather than inventing a new scheme.  And the reason for doing that is to
take advantage of the network effect -- to exploit the enormous
installed base of the HTTP protocol as a fall-back or bootstrapping
protocol for those (many!) cases where the agent is unaware of the new
protocol.  So if anything, I think it's more about "smartening up" http
URIs than dumbing anything down.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 10 Aug 2009 12:33:09 -0700

On Aug 9, 2009, at 7:24 PM, Daniel R. Tobias wrote:

> indicate particular protocols, while the other parts don't.

That is a common misconception.  The URI scheme names the mechanism
of name assignment, not the protocol used to access the resource.

The "http" scheme, in particular, uses several indirect name
resolution services (DNS) to associate with an Internet address
for which the owner of that address may install a TCP listener
on the given port (default 80) that will accept an HTTP request
message containing the path and query portion of the URI and
respond with an indication of whether that name is valid or invalid.
It is the fact that the owner of the hostname can control the
authoritative name resolver for supplying an address, has the
power to control what server is installed at that address, and
that an HTTP server has an almost unbounded remainder to use
for naming within that address, which makes the "http" scheme a
good mechanism for delegated naming.

Once a name is minted, however, there is no implication that
HTTP is used for operations on that named resource.  Such
implications are determined by context and use -- such as
the context of an anchor reference within HTML being activated
by a browser that does not already have a fresh cached copy
of a response for that identified resource.  Thus, it would
be possible for a context to say "use websocket" even if the
addressing mechanism were a telnet URI.

This is easier to grasp if you consider how many different
URI schemes can be used via an HTTP proxy server.  "http" is
just one of those schemes.  Some people use elaborate cloud
multitasking protocols as a proxying mechanism to obtain a
representation from a cache mesh -- "http" is just the naming
mechanism.

....Roy

---

From: Kristof Zelechovski <[email-masked]>
Date: Tue, 11 Aug 2009 18:35:46 +0200

1.  The document "Converting New URI Schemes or URN Sub-Schemes to HTTP"
[1] specifically addresses the use case where the custom URL is presented to
a casual user.  Since there are no legitimate casual users of the Web
Sockets protocol that is designed to be used by Web applications only, there
are no benefits to introducing the additional complexity of using an http
alias.

 2.  Additionally, the proposed solution of using the URI prefix
"http://wss.example/" is suited for custom protocols, according to the
description at [1].  A protocol promulgated by the WWW Corporation can
hardly be viewed as custom.

IMHO,
Chris

[1] <URL:http://dbooth.org/2006/urn2http/>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Booth
Sent: Friday, August 07, 2009 3:17 PM
To: Ian Hickson
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Uri-review] ws: and wss: schemes

-- 
David Booth, Ph.D.

---

From: Kristof Zelechovski <[email-masked]>
Date: Tue, 11 Aug 2009 22:34:32 +0200

Whether the readability disadvantage of having a longer aliased prefix is
serious depends on how often such code has to be written or used.  If Web
application developers feel the need to say { ws+"host/path" } instead of {
"ws://host/path" }, the hypercorrectness has really gone over the edge.

IMHO,
Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Booth
Sent: Monday, August 10, 2009 3:52 AM
To: Daniel R. Tobias
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Uri-review] ws: and wss: schemes

-- 
David Booth, Ph.D.

---

From: Kristof Zelechovski <[email-masked]>
Date: Tue, 11 Aug 2009 23:13:54 +0200

The Web Socket API is currently described by
<URL:http://www.whatwg.org/specs/web-workers/current-work/>.
HTH,
Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Booth
Sent: Saturday, August 08, 2009 2:22 AM
To: Ian Hickson
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Uri-review] ws: and wss: schemes

-- 
David Booth, Ph.D.

---

From: David Booth <[email-masked]>
Date: Tue, 11 Aug 2009 17:19:03 -0400

> are no benefits to introducing the additional complexity of using an http

I respectfully disagree.  I think it is a virtual certainty that if the
WSS protocol is useful, it will be used in ways far beyond its original
intent.  I don't think it would be wise to artificially constrain the
applicability of a new protocol by claiming that casual users are not
'legitimate'.

> hardly be viewed as custom.

I don't know exactly what you mean by "custom protocol", but WSS is
*exactly* the kind of protocol that [1] was talking about.  The
introduction uses "XyzConsortium" as an example, but you can think "WWW
Corporation" instead.

David

---

From: Kristof Zelechovski <[email-masked]>
Date: Tue, 11 Aug 2009 23:56:08 +0200

A "custom protocol" is, using David's terms, an owner-dependent protocol,
whereas a "standard protocol" is an owner-independent protocol.  "Owner" is
the owner of the aliasing domain.  A protocol is owner-dependent if the
server is guaranteed to belong to the owner (e.g. a bank or an ISP).
HTH,
Chris

-----Original Message-----
From: David Booth [mailto:[email-masked]] 
Sent: Tuesday, August 11, 2009 11:19 PM
To: Kristof Zelechovski
Cc: 'Ian Hickson'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Uri-review] ws: and wss: schemes

David

---

From: Kristof Zelechovski <[email-masked]>
Date: Wed, 12 Aug 2009 00:16:17 +0200

HTTP resources can be loaded from the browser cache without connecting to
the host.  This process is described by the HTTP protocol specification,
accordingly, it is part of the protocol.  You cannot claim the HTTP protocol
is not being used in this scenario.

OTOH, since FTP resources can be retrieved using an HTTP gateway, an FTP URL
does not guarantee that the client uses FTP to retrieve the resource.  This
process also has a side effect of adding the content type specification.

IMHO,
Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Roy T. Fielding
Sent: Monday, August 10, 2009 9:33 PM
To: Daniel R.Tobias
Cc: [email-masked]
Subject: Re: [Uri-review] ws: and wss: schemes

....Roy

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 12 Aug 2009 09:59:47 +1000

> applicability of a new protocol by claiming that casual users are not

And this is EXACTLY where I have a big problem with the process to date.

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.

I really believe that we should pause and consider the big picture.

It should be the IETF's remit to design a bidirectional protocol
for the web that is usable by a wide range of possible uses.

The W3C's websocket API should be just one consumer of that
protocol.

I really think that the hybi effort needs to be elevated to a
working group to progress this.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 11 Aug 2009 17:23:45 -0700

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

Regards,
Maciej

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 12 Aug 2009 03:19:26 +0100

Kristof Zelechovski wrote:
> a casual user. 

> Since there are no legitimate casual users of the Web
> Sockets protocol that is designed to be used by Web applications only,

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

That's a legitimate use.

-- Jamie

---

From: David Booth <[email-masked]>
Date: Tue, 11 Aug 2009 22:52:26 -0400

> existing resource, or being misinterpreted by a legacy client (instead  

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.

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 11 Aug 2009 20:08:54 -0700

> meaning as a WSS URI for those agents that know how to handle the WSS

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.

Regards,
Maciej

---

From: David Booth <[email-masked]>
Date: Tue, 11 Aug 2009 23:27:38 -0400

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

> is not necessarily a disadvantage, but it doesn't seem like much of an  

Jamie Lokier just gave one:
http://lists.w3.org/Archives/Public/uri/2009Aug/0011.html

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

> Parties

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 11 Aug 2009 20:38:34 -0700

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

> 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

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 12 Aug 2009 05:49:21 +0100

> server. We know from experience that this doesn't scale.

There should be no requests to that server.
It's similar to XML namespaces, which should never be dereferenced.

But maybe you have a point.  The mere occurrence of
"http://wss.example.com/some/path" embedded in script in a web page
will probably cause some (non-browser) agents to attempt to fetch the
resource at that URL.  Cheap spidering.

  -- Jamie

---

From: David Orchard <[email-masked]>
Date: Tue, 11 Aug 2009 20:46:34 -0700

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<[email-masked]> wrote:
> 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 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Kristof Zelechovski <[email-masked]>
Date: Wed, 12 Aug 2009 12:15:09 +0200

1.  Encouraging the user to enter a Web Sockets URL does not make sense if
cross-domain connections are not allowed, which I hope will be the case (the
draft specification [1] does not contain security considerations).

 2.  While we are at it, a Web Sockets connection is useless without knowing
the protocol, and the protocol to be used is not contained within the URL.
That means a ws URL is not self-contained and thus useless as a stand-alone
locator.

IMHO,
Chris

[1] <URL:http://dev.w3.org/html5/websockets/>

-----Original Message-----
From: Jamie Lokier [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2009 4:19 AM
To: Kristof Zelechovski
Cc: 'David Booth'; 'Ian Hickson'; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [hybi] [Uri-review] ws: and wss: schemes

That's a legitimate use.

-- Jamie

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Aug 2009 09:22:42 +0200

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

There's a new draft: 
<http://www.ietf.org/id/draft-hixie-thewebsocketprotocol-32.txt> (BTW: 
just because publishing I-Ds is so simple doesn't mean that every single 
change needs to be published right away; it's a distraction and also 
confuses people about when they are supposed to review).

Anyway, it now says:

>    URI scheme syntax.
>       In ABNF terms using the terminals from the IRI specifications:
>       [RFC5238] [RFC3987]
> 
>            "ws" ":" ihier-part [ "?" iquery ]

That is even worse than before, because it now uses productions from the 
IRI spec defining *URI* syntax.

Furthermore, it still doesn't answer what the semantics of these parts 
are. What do "ihier-part" and "iquery" represent in a ws URI? What'S the 
effect? How are they used?

BR, Julian

PS: what does RFC5238 have to do with this?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 Aug 2009 09:39:36 +0200

Ian Hickson wrote:
>> 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?)

Just day "STD68" instead of "RFC5234" in the reference/@anchor element.

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

You can only have ASCII characters in a URI. I believe you're trying to 
do the right thing, but it really requires a few more words (...when 
non-URL characters are to be used in a ws URI, they need to be encoded 
using UTF-8 and then percent-escaped...)

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

Maybe than that spec should carry the URI definition and registration.

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

Looking at relatively recent RFCs, and example would be 
<http://tools.ietf.org/html/rfc4516#section-2>.

If there is no defined semantics for the two parts then the definition 
should just state that.

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Fri, 14 Aug 2009 07:15:41 +0000 (UTC)

On Fri, 7 Aug 2009, Julian Reschke wrote:
> > Socket protocol, will be available in the Web Socket protocol ID as soon as
> > the IETF upload process completes:
> > 

Thanks, fixed.

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

> remainder of the spec. So is the IANA registration template supposed to 

Yes.

> 1) What does a "ws" URI identify?

I have added text speaking to this.

On Fri, 7 Aug 2009, Greg Wilkins wrote:
> 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 

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, Pieter Hintjens wrote:
> 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?
> 
> 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.

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

> 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:
> 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 [email-masked] 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:
> 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.
> 
> 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

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 14 Aug 2009 22:37:54 +0100

> draft specification [1] does not contain security considerations).

It was originally thought XHR (XmlHttpRequest) didn't need to be
cross-domain, but then people thought of lots of reasons why it's
useful and had to use hacks to workaround the limitation, so now
there's a draft standard to support cross-domain XHR - being careful
to address cross-domain security.

I suspect WebSockets could benefit from a look at the mechanisms used
by cross-domain XHR to check for permission to proceed.

> That means a ws URL is not self-contained and thus useless as a stand-alone

The same is true of HTTP.

A HTTP URL does not tell you the type of resource, only where to find
_a_ resource.  For example there are places where a user can enter the
URL of a CalDAV calendar resource.  The CalDAV protocol is used (over
HTTP) to work with that resource, but the URL doesn't say what it is.

The only difference with WebSockets is that it (so far) seems to avoid
any descriptive metadata, which means there will still be applications
which ask for a WebSockets URL, but when the URL is for a different
protocol on top, it'll simply break with undefined behaviour instead
of a clean error message or fallback behaviour.

It doesn't matter if you think nobody should do that.  It will still
be done anyway - because it's so obviously useful.

-- Jamie

---

From: Křištof Želechovski <[email-masked]>
Date: Sat, 15 Aug 2009 01:50:01 +0200

1.  Maybe it is just me but I cannot see how breaking with undefined
behavior could be obviously useful.  Undefined behavior might as well amount
to accidentally starting WW III.
 2.  If we do not want spiders to connect to Web sockets, it seems using a
special URL scheme is a way to prevent this, and therefore it would be
desirable.
Chris

-----Original Message-----
From: Jamie Lokier [mailto:[email-masked]] 
Sent: Friday, August 14, 2009 11:38 PM
To: Kristof Zelechovski
Cc: 'David Booth'; 'Ian Hickson'; [email-masked]; [email-masked];
[email-masked]

-- Jamie

---

From: Erik Wilde <[email-masked]>
Date: Sat, 15 Aug 2009 22:25:49 -0700

On Aug 14, 2009, at 0:39, Julian Reschke <[email-masked]> wrote:
>> That the only encoding that can be used with this scheme is UTF-8.  
>> What is unclear?
> You can only have ASCII characters in a URI. I believe you're trying  
> to do the right thing, but it really requires a few more words  
> (...when non-URL characters are to be used in a ws URI, they need to  
> be encoded using UTF-8 and then percent-escaped...)

i think there is some misunderstanding here: "encoding" here refers to  
the encoding of the URI (as julian has pointed out in his response),  
not the encoding of the payload of the protocol that is used to  
interact with resources identified by the URI.

cheers,

dret.

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 16 Aug 2009 18:49:18 +0100

>Jamie Lokier wrote:

> to accidentally starting WW III.

You misunderstood; sorry I must have been unclear.

*Breaking with undefined behaviour* is not useful.

Being able to connect to user-specific resources is very useful, even
if there is no way to be sure the resource is using the right
protocol, other than simply trying it.

Think about it:

   - Every GUI email application lets you say which server and port to
     use for POP3, IMAP and SMTP.
   - Every blog and picture posting application lets you say which URL
     to use for posting, even letting you use non-standard ports.
   - Every WebDAV remote file manager lets you say which HTTP URL to
     connect to for WebDAV service.
   - Every CalDAV calender application lets you say which HTTP URL to
     connect to for calender service.

Always, the user can enter bogus information and undefined behaviour
follows.  But the ability for the user to enter it is what makes those
applications useful; that benefit far outweighs the problems.

We like to avoid undefined behaviour if possible, so it's _better_ to
have protocols with some basic, de facto standardised self-checking
before proceeding with something dangerous.  HTTP is good at this when
methods or unusual headers are used for checking, and bad at this when
the protocol consists of just GET or POST.

WebSockets philosophy seems to be to check for WebSockets itself, but
then avoid the problem at the next level, passing it on to the
application to do an initial handshake, which has the same problems as
raw TCP in that there is no _standard_ negotiation handshake.

You can be absolutely sure that as soon as there are useful web
applications using WebSocket, there will be non-browser clients using
the same protocols and the servers won't even know.

For example, imagine a real-time web-based map which shows movement of
vehicles on a map, using WebSockets to get real-time movement updates.

It won't be long before an unrelated third party writes a non-browser
app which queries the server to get the same information, and that
non-browser app will have to implement the same WebSockets
protocol.

> special URL scheme is a way to prevent this, and therefore it would be

1. If HTTP URLs are used, spiders will do HTTP GET requests which won't
   be a problem - a WebSockets-only service will just reject the request.

2. robots.txt.

3. It will add some load.  It shouldn't be a lot of load, because
   WebSockets-only URLs would tend to appear in Javascript, where most
   spiders would tend not to follow them.  But remember that some
   spiders are unfriendly.

So I think that's not a strong argument either for or against a
different URL scheme.

-- Jamie

---

From: [email-masked]
Date: Wed, 19 Aug 2009 12:23:37 -0400

Jamie Lokier writes:

> A HTTP URL does not tell you the type of resource, only where to 
> find _a_ resource.

This misses an important point about http URIs and the HTTP protocol. 
Although the URL itself does not tell you the type of the resource, the 
response to an HTTP GET does indeed tell you the type of the entity body. 
So, you can access any such URI on the Web, and you'll either: (1) know 
how to interpret the response, I.e. because you recognize the Content-type 
and know how to process data of that type, or (2) will reliably discover 
that it's of a type you don't know how to process.  These characteristics 
are what make it possible for you to click on any link, and know that your 
browser won't misinterpret the results, even as new Content-types are 
deployed (well, let's not get into the sniffing discussion just now). It's 
also what allows search engine spiders to interpret the results returned 
from GETs on pretty much any http link.

So, this is a desirable characteristic for Web resources, and it's one of 
the things that HTTP gives you.  Indeed, the whole Web is designed so that 
you can start with RFC 3986, the specification for URIs, and using the 
references to which it (recursively) delegates, discover how to correctly 
interact with and interpret responses from any resource on the Web.  Under 
the auspices of the W3C TAG, I prepared a "finding" [1] that goes into 
more detail on these issues and their implications.

BTW: the above comment is not intended to express an opinion about the 
proposed ws/wss URI schemes; it's a reaction to Jamie's comment.  I do 
think it is an interesting question (I think I've raised it before), 
whether we expect search engines to come on ws/wss links, and if so, 
whether it's valuable for those search engines to be able to discover 
information about the resources identified by those links.

Noah

[1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Jamie Lokier <[email-masked]>
Sent by: [email-masked]
08/14/2009 05:37 PM
 
        To:     Kristof Zelechovski <[email-masked]>
        cc:     "'David Booth'" <[email-masked]>, "'Ian Hickson'" 
<[email-masked]>, [email-masked], [email-masked], [email-masked], (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        Re: [hybi] [Uri-review] ws: and wss: schemes

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 19 Aug 2009 17:46:18 +0100

> from GETs on pretty much any http link.

Firstly, I agree with the usefulness of Content-Type, which is why I
think it would be helpful if the WebSockets protocol defined something
equivalent, even just a single string to identify the protocol at the
start.

Secondly, this thread has talked about protocols on top of protocols
(because every WebSockets application will be one).  Given a URI, you
cannot tell from Content-Type whether that URI supports WebDAV, and
you cannot tell whether that URI accepts POSTs to submit new blog
entries - just to pick two widely used examples.

That requires another level of descriptive metadata, which
Content-Type does not provide and is not always available in any other
form.  But, just like people can enter a "blog posting" URI into their
mobile phone, there will be reasons why people enter WebSockets URIs
into applications, with no way for the application to verify the
protocol except by trying it.

> So, this is a desirable characteristic for Web resources, and it's
> one of the things that HTTP gives you.  Indeed, the whole Web is
> designed so that you can start with RFC 3986, the specification for
> URIs, and using the references to which it (recursively) delegates,
> discover how to correctly interact with and interpret responses from
> any resource on the Web.  Under the auspices of the W3C TAG, I
> prepared a "finding" [1] that goes into more detail on these issues
> and their implications.

In other words, I disagree with the above.  You can't find which
particular protocols are overlaid on top of HTTP at every findable URI
by the existing mechanisms, and it's unlikely that will ever be
possible.

> I do 

It's an intersting question, but please don't get too sidetracked from
the (imho) more important question of ensuring that specific web
applications can connect to WebSockets resource whose URI is provided
by a third party, with a reasonable level of safety and security.

-- Jamie

---

From: [email-masked]
Date: Wed, 19 Aug 2009 15:13:44 -0400

Jamie Lokier writes:

> That requires another level of descriptive metadata

You're pointing out that the Web doesn't use static interface 
descriptions, except insofar as the rules for HTTP and URIs are set out in 
advance.

On the Web, you don't ask for static metadata that answers the question: 
"if I were to try a WebDav HTTP method on URI X, would it work?"  You try 
it.  HTTP tells you whether it worked, and if it did, gives back 
information that is interpretable (relatively) unambiguously per the 
specifications for URI (RFC 3986), which delegate to HTTP (RFC 2616), 
which in turn delegates to the media-type registration for the 
Content-type, etc.

FWIW: Web Services with WSDL take the opposite approach.  Web services do 
tend to emphasize static interface descriptions, advertised in advance. 
While there's endless gnashing regarding the pros and cons, it's along the 
lines of:  advance descriptions can be aids to tooling, debugging, and 
sometimes optimization, but dynamically negotiated contracts are usually 
more flexible.  In particular, I don't think the Web would work nearly as 
well if each URI had to advertise in advance:  "if you try a GET, I'll 
support it, and you'll get an image/jpeg".  Just do the GET, or WebDav, 
and see what happens.

Anyway, I thing we should wrap up this aspect of the discussion.  There 
are indeed some interesting questions as to how self-describing the 
websocket protocols should be, but here I think we're mainly concerned 
with the choice of URI scheme. 

Noah

---

From: John Kemp <[email-masked]>
Date: Wed, 19 Aug 2009 13:50:52 -0400

...

>  Given a URI, you
> cannot tell from Content-Type whether that URI supports WebDAV,

However, the WebDAV specification does specifically offer some level of 
compatibility with existing non-WebDAV-aware clients - 
http://tools.ietf.org/html/rfc4918#appendix-B

Without a WebDAV-aware client, I can still perform some non-WebDAV HTTP 
requests.

With a WebDAV-aware client, I can perform WebDAV HTTP requests which the 
server may or may not support, but the server can tell me, according to 
HTTP specification that a "method is not supported".

> and

A client able to submit a POST can try, but might fail.

> protocol except by trying it.

The question is perhaps really about whether you want to provide _some_ 
compatibility with existing non-websock-aware clients.

> by the existing mechanisms, and it's unlikely that will ever be

It is possible for those designing Web protocols to consider 
compatibility with existing Web client software, and to provide ways of 
allowing new and existing clients to determine the capabilities of 
HTTP-identified resources. The TAG finding that Noah mentions describes 
ways in which (some) others have allowed for clients to "follow their 
noses" and discover how to operate with servers regarding particular 
resources. There are other ways to do it, but the point is that it 
depends on protocol designers making the decision to offer such 
facilities. Using HTTP URIs to identify resources is a good way to begin 
that process.

Regards,

- johnk