Subject: [hybi] 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: Ian Hickson <[email-masked]>
Date: Fri, 7 Aug 2009 19:40:24 +0000 (UTC)

On Fri, 7 Aug 2009, David Booth wrote:
>
> 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.

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

---

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: 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: 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: David Booth <[email-masked]>
Date: Sun, 09 Aug 2009 21:52:02 -0400

On Fri, 2009-08-07 at 21:30 -0400, Daniel R. Tobias wrote:
> 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.

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.

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

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.  

-- 
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: 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: Maciej Stachowiak <[email-masked]>
Date: Tue, 11 Aug 2009 20:08:54 -0700

On Aug 11, 2009, at 7:52 PM, David Booth wrote:

> On Tue, 2009-08-11 at 17:23 -0700, Maciej Stachowiak wrote:
> 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.

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: Maciej Stachowiak <[email-masked]>
Date: Tue, 11 Aug 2009 20:38:34 -0700

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

> On Tue, 2009-08-11 at 20:08 -0700, Maciej Stachowiak wrote:
> You've misunderstood.  This would not apply to arbitrary hosts whose
> name starts with "wss".  Please re-read

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.

> 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

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: 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: Jamie Lokier <[email-masked]>
Date: Fri, 14 Aug 2009 22:37:54 +0100

Kristof Zelechovski wrote:
>  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).

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.

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

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

> 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: 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: David Booth <[email-masked]>
Date: Tue, 11 Aug 2009 23:27:38 -0400

> Parties

---

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

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: [email-masked]
Date: Wed, 12 Aug 2009 09:47:46 -0400

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

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.

Noah

[1] http://tools.ietf.org/html/draft-hammer-discovery-02
[2] http://lists.w3.org/Archives/Public/uri/2009Aug/0027.html

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

---

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: 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: 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: [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

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

---

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: Mark Nottingham <[email-masked]>
Date: Thu, 20 Aug 2009 09:34:07 +1000

I really hesitate to wade into what looks like another huge rat-hole.

Using HTTP for XRIs seemed like a good idea because XRI was trying to  
re-invent URIs, and not define a protocol; HTTP gave them a default  
protocol, as it were, in case you ever did want to interact with them.

WebSockets is defining a protocol, and so is a very different case. It  
is definitely not HTTP.

I can't help but feel that if we follow the arguments given in this  
thread, there won't be any need for FTP, or telnet, or any other URI  
schemes; all will be subsumed by HTTP, and eventually we won't need  
any URI schemes at all (because it's HTTP all the way down).

While that's one possible future, I suppose, I think it's pretty far  
off. Certainly, trading off in-URL metadata in the scheme for more in  
the path component (as proposed earlier in this thread) is an ugly  
hack at best. Other extra-URL metadata approaches need to be proven  
(especially around performance issues), as well as accepted by  
implementers, because what's really being proposed is an extra layer  
of protocol discovery on top of WebSockets using HTTP.

As it stands, URIs still have schemes, and we still have mechanisms  
for defining new ones. If folks want to argue that we shouldn't, the  
best way to do that would be to get a standards-track document that  
obsoletes the relevant RFCs, rather than blocking individual  
registrations.

Cheers,

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 20 Aug 2009 01:59:33 +0100

Fwiw, I agree with Mark that we should not be shy about using new
schemes for new protocols that are not HTTP.

Only things which run _over_ HTTP should use be using HTTP URIs, and
WebSockets does not run over HTTP... but:

> WebSockets is defining a protocol, and so is a very different case. It  

That's correct, WebSockets is not HTTP.

However it does begin with an HTTP connection and an HTTP request, to
a server which may be serving other HTTP resources on the same port.

Quite possibly over port 80, and in the process trip over HTTP proxies.

So it's not really the same as telnet, FTP etc.

Three notable things for which there is no consensus(*) are:

  1. Does the WebSockets really have to use a fresh, new TCP
     connection for every individual instance of the WebSockets object
     created on every web page in a browser to the same site?  Or
     could it upgrade an HTTP connection which has already been used
     for something else?

  2. Since it begins with an HTTP request for upgrade to WebSockets,
     is there any reason for that request not to be to an arbitrary
     HTTP host+port+path by simply trying the upgrade method on the
     appropriate HTTP path at the server?

  3. If a WebSockets connection cannot be established, clients
     will(**) fall back to an equivalent (but bulkier/slower) protocol
     which uses HTTP only.  What URI will they use in that case?  Do
     we leave it to individual application/framework designers, or do
     we suggest a common strategy?

* -  Although it has been asked if the protocol is a "politically agreed"
     foregone conclusion (due to an earlier message) and therefore if
     we are wasting our time with design discussions.

** - As in, even if the spec does not provide this and browsers do not
     provide it, there will certainly be Javascript
     WebSockets-emulation modules and corresponding server-sides which
     do.  We can choose to ignore this and leave the mapping from
     WebSockets URI to HTTP-fallback URI unspecified, or recommend
     a mapping, or they can simply by the same URI given point 2.

-- Jamie

---

From: Erik Wilde <[email-masked]>
Date: Wed, 19 Aug 2009 18:44:18 -0700

hello mark.

Mark Nottingham wrote:
> schemes; all will be subsumed by HTTP, and eventually we won't need any 
> URI schemes at all (because it's HTTP all the way down).

http://dret.typepad.com/dretblog/2009/07/the-last-uri-scheme-youll-ever-need.html 
was something i wrote recently based on another instance where people 
were arguing that from now on, all we'll ever need is HTTP URIs and 
string matching to detect special classes of URIs, that can then be 
handled differently, if an application has knowledge of the pattern that 
needs to be matched.

while the argument for string matching for "special URIs" has been 
repeated a number of times, i still haven't seen any example in real 
life where this happened in the way predicted: plain HTTP users 
discovering useful metadata or getting useful fallback behavior, and 
other applications doing string matching and implementing non-HTTP 
behavior. are there any examples where this has happened on any 
significant scale?

cheers,

dret.

---

From: [email-masked]
Date: Thu, 20 Aug 2009 12:32:06 -0400

> a server which may be serving other HTTP resources on the same port.

I think the use case that makes an http scheme potentially interesting is:

Some application is using these ws: or wss: URIs.  The URIs wind up in 
documents or in other places where they can be discovered, perhaps because 
that is how the application keeps track of or advertises various web 
socket endpoints.  Now some other agent, perhaps a search crawler, comes 
upon the documents and finds the references.  If they are http-scheme 
URIs, then the crawler will know how to dereference them.  Of course, this 
agent will not go through the upgrade protocol, and will attempt an 
ordinary HTTP GET.  If the server (I.e. the same software that would have 
processed the Web socket upgrade) chooses to, it can respond with metadata 
explaining that this is a Websocket resource, perhaps providing 
information about its purpose and correct use, etc.  The means for 
returning that metadata might be along the lines of [1].  That 
discoverability seems to have some value. 

Interestingly, the fact that Websockets uses an HTTP-compatible initial 
handshake makes this achievable in practice, I think.

Ian Hickson wrote (earlier in this thread)

> > So, here's an example.  First, let's make the assumption thatthere is 
> > Where's the value?  Let's assume that a link to a WS resourcewinds up 

> more than it does to telnet or SSH connections? If so, why?

In principle, probably no, or mostly no; the cases are indeed quite 
similar.  It would be nice to have a uniform protocol for a user agent to 
at least find out >something< about such URIs.  That said, ftp and telnet 
have been widely deployed since the early days of the Web.  To some 
degree, those user agents that want to interact with or learn about ftp or 
telnet resources tend to be coded to understand them.

Websockets seem different in two ways, one of which is more or less a 
happy accident:

1) Websockets are new, so there's an awful lot of software out there that 
will just not recognize the new schemes at all.
2) (happy accident) I suspect the choice of an HTTP-compatible handshake 
was made to get through firewalls, but I think it also facilitates the use 
of HTTP for metadata discovery for web socket resources.

I do see both sides of the "use ws:" vs "use http:" question.  Web socket 
endpoints are not documents (or "Information Resources" [2] in the 
language of AWWW), suggesting that new schemes are indeed appropriate; 
using http:://websockets.org or the like is indeed a bit tricky and 
confusing.  HTTP is at best usable for finding metadata about the Web 
socket.  So, I think there are advantages both ways.

FWIW:  the case has been made that ws: and wss: scheme URIs will mostly 
appear in code that is private to individual applications, as opposed to 
being widely published on the Web.  That being the case, I wonder whether 
it would be better to leave these convenient short names free for future 
use, and to choose something a bit longer for Web sockets?  In general, it 
seems a good thing to allocate short names beginning with the letter "w" 
with a bit of care, given that things on the Web tend to be called "Web 
xxxx" (in this case, "Web Sockets").

Noah

[1] http://tools.ietf.org/html/draft-hammer-discovery-03
[2] http://www.w3.org/TR/webarch/#def-information-resource

08/19/2009 08:59 PM
 
        To:     Mark Nottingham <[email-masked]>
        cc:     URI <[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: Thu, 20 Aug 2009 20:01:57 +0100

[email-masked] wrote:
 If the server (I.e. the same software that would have 
> discoverability seems to have some value. 

Hey, I like that idea.  Wish I'd thought of it :-)

For round-trip reduction I favour being able to try an upgrade
request, with your own optional headers, and have the server reject it
if it doesn't see what it wants, perhaps referrring to the information
you've described.  It also leaves the door for servers to respond with
different protocols depending on the request - in the same way as SSH1
and SSH2 are negotiated, for example, without needing extra round-trips.

That looks a *lot* like HTTP negotiation, and people are very
familiar with that.  Servers have good support for it too.

> Web socket endpoints are not documents (or "Information Resources"
> [2] in the language of AWWW), suggesting that new schemes are indeed
> appropriate;

I agree.

A comet server on http://cometd.org.example/cometd.cgi?protocol=bayeux
(example may not be realistic) is not a document in any useful sense
either.  Where are we going with this?  Should that become a legacy
hack?  Should we have a different scheme for all
"protocol-over-HTTP-misused-as-a-transport"?

> 2) (happy accident) 

> I suspect the choice of an HTTP-compatible handshake was made to get
> through firewalls,

I suspect it was so that it could connect to random servers and get a
useful error message if they don't support WebSockets (that has been
explained on the hybi list), and to connect to servers which are
handling HTTP on the same port.

For getting through firewalls - including ISPs who don't firewall but
are running intercepting proxies on port 80 - I think it's basically
going to fail at that because it doesn't consider proxy issues at all
- and because UPGRADE has never been deployed (as far as I know).  But
to be honest I don't know if it'll fail as much as I think in the real
world without measurements from a wide range of internet locations.
I'm not the only person who thinks so, though.

-- Jamie

---

From: [email-masked]
Date: Mon, 24 Aug 2009 16:19:35 -0400

> Hey, I like that idea.  Wish I'd thought of it :-)

I can't honestly tell if you're agreeing with me or gently pulling my leg. 
 If the former, then this is a reason to use an http-scheme URI.  Thanks.

Noah

08/20/2009 03:01 PM
 
        To:     [email-masked]
        cc:     Ian Hickson <[email-masked]>, [email-masked], Mark Nottingham 
<[email-masked]>, URI <[email-masked]>
        Subject:        Re: [hybi] [Uri-review] ws: and wss: schemes

I agree.

-- Jamie