Subject: [hybi] web socket protocol in "last call"?

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Oct 2009 08:20:14 +0100

Citing <http://blog.whatwg.org/html5-at-last-call>:

"There's also a version of the spec called Web Applications 1.0 (for 
nostalgic reasons) that has all of the above as well as a number of 
other specs, namely Web Storage, Web Database, Server-sent Events, and 
the Web Sockets API and protocol, all together in one document. With the 
exception of the Web Database spec, they're all now in last call at the 
WHATWG."

Ian, could you please explain what you mean by "last call" in this context?

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Wed, 28 Oct 2009 08:12:17 +0000 (UTC)

> Ian, could you please explain what you mean by "last call" in this 

We're starting to see implementations of the WebSocket protocol, so I 
wanted to encourage comments from the wider Web authoring community before 
it's too late (i.e. before we are frozen by shipped implementations). In 
the conventions we're using at the WHATWG (based on the W3C terminology), 
the stability of spec sections is goes through First Draft, then Working 
Draft, then Last Call, then Candidate Recommendation. (This corresponds 
roughly to the formal WHATWG stages "Working Draft", "Call For Comments", 
and "Call For Implementations" as described in the WHATWG charter.) You 
can see the state of each section in the WHATWG draft by looking at the 
little boxes in the right hand margin.

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Oct 2009 09:24:36 +0100

Ian Hickson wrote:
> ...

"Freezing" the protocol by having implementations being shipped *now* 
seems to be a problem if the protocol is supposed to become a work item 
of a future IETF WG.

BR, Julian

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 28 Oct 2009 10:54:02 +0200

Hi Ian,

the  WebSocket protocol is already an IETF draft so
It is not fair to start a last call in a different community to freeze 
the protocol without announce it
also in the IETF mailing list and ask if IETF people agree on freezing 
the protocol.
As WebSocket protocol is an Internet draft it should follow the IETF rules.

Moreover I have seen a lot of mail exchanges raising possible problems 
in the current version of the WebSocket draft
that you should consider and address in the draft or provide to the IETF 
community good technical reasons why you choose to not consider them

BR
Sal

Julian Reschke wrote:
>>> other specs, namely Web Storage, Web Database, Server-sent Events, 
>>> and the Web Sockets API and protocol, all together in one document. 
>>> With the exception of the Web Database spec, they're all now in last 
>>> call at the WHATWG."
>>>
>> wanted to encourage comments from the wider Web authoring community 
>> before it's too late (i.e. before we are frozen by shipped 
>> implementations). In the conventions we're using at the WHATWG (based 
>> on the W3C terminology), the stability of spec sections is goes 
>> through First Draft, then Working Draft, then Last Call, then 
>> Candidate Recommendation. (This corresponds roughly to the formal 
>> WHATWG stages "Working Draft", "Call For Comments", and "Call For 
>> Implementations" as described in the WHATWG charter.) You can see the 
>> state of each section in the WHATWG draft by looking at the little 
>> boxes in the right hand margin.
>> ...
>
> seems to be a problem if the protocol is supposed to become a work 
> item of a future IETF WG.
>
> BR, Julian
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Ian Hickson <[email-masked]>
Date: Wed, 28 Oct 2009 09:56:16 +0000 (UTC)

On Wed, 28 Oct 2009, Salvatore Loreto wrote:
> It is not fair to start a last call in a different community to freeze the
> protocol without announce it
> also in the IETF mailing list and ask if IETF people agree on freezing the
> protocol.

I don't think anyone is suggesting intentionally freezing the protocol. 
The WHATWG announcement was just a call for comments.

It is the case, however, that once we have multiple interoperable 
implementations, regardless of where we stand with respect to the process 
here or at the WHATWG, the protocol will be essentially frozen on us, 
whether we like it or not. (Well, we could change it further, but then 
we'd just be ignored.) I expect this to happen in the coming months.

> As WebSocket protocol is an Internet draft it should follow the IETF rules.

It's also a WHATWG draft, so it should also follow the WHATWG rules. :-)

> Moreover I have seen a lot of mail exchanges raising possible problems in the
> current version of the WebSocket draft

There's a couple of e-mails from earlier today that I haven't yet 
considered, but other than that, I've read and considered all the e-mails 
to this list, and provided detailed reasons for rejecting any proposals 
I've not adopted. If I missed one, please let me know.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Oct 2009 11:26:35 +0100

> The WHATWG announcement was just a call for comments.

It appears it's not relevant whether it's intentionally or not.

> whether we like it or not. (Well, we could change it further, but then 

Well, we could tell implementers not to ship with that feature. 
Actually, we should.

> It's also a WHATWG draft, so it should also follow the WHATWG rules. :-)

In which case you should clarify what this means in practice, because it 
should be considered when chartering the Working Group.

BR, Julian

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 28 Oct 2009 17:36:51 +0200

> On Wed, 28 Oct 2009, Salvatore Loreto wrote:
<snip>
Hi Ian,

actually in the IETF process one of the main reason to accept or reject 
a proposal/issue/"request to change something"
is based on *"rough consensus"* reached among people involved in the 
mailing list discussion ,
especially when the reason for accepting or rejecting are based more on 
philosophical then technical issues.

The decision to adopt or not a proposal should come from the consensus 
and not from the decision of a single person.
I am sorry to notice, following the ml discussion, that a lot of the 
proposals have been discarded for philosophical reasons
even if the majority of the people in the ml were in favour.
I am not saying that you should adopt them straight, but only that you 
should keep open the discussion on controversial
issues and seek a sort of consensus, among people involved in the 
discussion, on how to solve them

/Sal

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Wed, 28 Oct 2009 13:01:44 -0700

wow. WS is in last call? not being able to continue work on putting
something like RHTTP or BWTP over WS is a bit of a deal-breaker for
me.

but. i suppose there's no reason we can't work on BWTP independent of
WS. i was just sorta hoping there would have been a way to coordinate
these efforts.

i guess there's also no reason now to meet at apachecon next week
about WS. i mean, why bother meeting about something you can't change?

however, if anyone wants to meet about BWTP at apachecon, i'm totally
hip to that. also, krunk. i'm not going to be in hiroshima for the
hybi BoF, but i would advocate strongly for including something like
BWTP as a deliverable alongside WS, assuming WS would be something for
HyBi instead of httpbis.

WS is essentially unusable for me in it's current form. or rather, i
could use it, but why? my use case of establishing reverse
request-response semantic recognizable by intermediaries that supports
channel multiplexing is possible over WS, but then again, it's also
possible by extending HTTP, so why not just do that?

-cheers
-meadhbh / infinity
--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Wed, Oct 28, 2009 at 08:36, Salvatore Loreto
<[email-masked]> wrote:
>> considered, but other than that, I've read and considered all the e-mails to
>> this list, and provided detailed reasons for rejecting any proposals I've
>> not adopted. If I missed one, please let me know.
>>
>
> Hi Ian,
>
> actually in the IETF process one of the main reason to accept or reject a
> proposal/issue/"request to change something"
> is based on *"rough consensus"* reached among people involved in the mailing
> list discussion ,
> The decision to adopt or not a proposal should come from the consensus and
> not from the decision of a single person.

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 28 Oct 2009 15:13:19 -0700

> about WS. i mean, why bother meeting about something you can't change?

WHATWG Last Call doesn't mean "can't change". It's just soliciting  
comments. And it is in no way binding on the IETF.

In practice, the factor that will reduce the rate of change in the  
future will be when implementations (client-side and server-side) ship  
and Web content starts using it.

WebKit has an implementation of the WebSocket API and protocol in  
progress. We do not anticipate that work reaching a freeze point in  
the very near future. We'll think about taking appropriate measures to  
avoid locking in the protocol when we ship, to give the IETF Working  
Group a chance to define the protocol.

Given all this, I do think meeting in person to discuss is useful.

Regards,
Maciej

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Wed, 28 Oct 2009 15:41:07 -0700

cool. that's good to hear. i think i was associating "last call" with
something more like AUTH48 in the IETF.

<random_babbling_on_a_public_list>

i'm still vaguely concerned about the state of WS as a substrate for
something like BWTP or RHTTP. but i think what i'm hearing is that WS
is approaching  consensus for the browser use case.

HyBi has a few people who are interested primarily in (bidirectional)
HTTP as a substrate for other application layer protocols. is there a
similar constituency in WHATWG? (probably should have asked this way
earlier.) in other words, while i think pushing HTML+JPEG over HTTP is
cool and about the only use case browser vendors are going to worry
about; my personal interest is in pushing xml, json, and random weird
BASE64 encoded binary blobs with metadata over the connection.

</random_babbling_on_a_public_list>

On Wed, Oct 28, 2009 at 15:13, Maciej Stachowiak <[email-masked]> wrote:
> WHATWG Last Call doesn't mean "can't change". It's just soliciting comments.
> And it is in no way binding on the IETF.
>
> In practice, the factor that will reduce the rate of change in the future
> will be when implementations (client-side and server-side) ship and Web
> content starts using it.
>
> WebKit has an implementation of the WebSocket API and protocol in progress.
> We do not anticipate that work reaching a freeze point in the very near
> future. We'll think about taking appropriate measures to avoid locking in
> the protocol when we ship, to give the IETF Working Group a chance to define
> the protocol.
>

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 29 Oct 2009 09:49:13 +1100

> possible by extending HTTP, so why not just do that?

I completely agree with this sentiment.   WS is usable, but provides
no significant benefit over HTTP other than a warm philosophical
feeling that you are not abusing HTTP, is a little more byte
efficient and marginally better latency.

But it is not going to scale for my use-cases because of the
connection bloat.   It's going to break all the load balancers
I work with, and the SSL offloaders and most other network
infrastructure.

I'll be interested to see what happens when intermediaries
notice ws trying to run around them.  Will they support it or
block it?   My money is on the later.

If it becomes a standard as is, we will support it... but hide
it in the basement, under the stairs behind a sign that says
"beware of the leopard".    It will be a novelty like HTTP
pipelining - you can turn it on and play with it, but will
not seriously consider using it in deployment other than in
very specific circumstances.

Failing consensus on the protocol, I would have really liked the
opportunity of having a service provider API in the browser - so
I could intercept standard ws API and transport it over something
that would work my use-cases, or inserting layers between
app API and transport.

Pity.  Opportunity lost.

regards

---

From: Martin Tyler <[email-masked]>
Date: Wed, 28 Oct 2009 23:04:04 +0000

I agree with Greg on this.

As another vendor of server software that could make use of this, in its
current form it would just be something we implement under the covers to
slightly improve things. However, if the solution to reverse proxies and
other such intermediaries causing issues is that they will block WebSockets
then we'd have to stick with our current 'comet hacks'.

We always advise our customers to put our servers Internet facing, but in
large organisations this isn't always possible - and thinking that anyone
wanting to run a WebSocket server will just have to get a proxy that
conforms or remove it all together is frankly naive.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Oct 2009 06:07:33 +0100

Maciej Stachowiak wrote:
> progress. We do not anticipate that work reaching a freeze point in the 
> very near future. We'll think about taking appropriate measures to avoid 
> locking in the protocol when we ship, to give the IETF Working Group a 
> chance to define the protocol.
> ...

Thanks for the clarification!

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Sat, 31 Oct 2009 03:35:33 +0000 (UTC)

On Wed, 28 Oct 2009, Salvatore Loreto wrote:
> > considered, but other than that, I've read and considered all the 
> > e-mails to this list, and provided detailed reasons for rejecting any 
> > proposals I've not adopted. If I missed one, please let me know.
> 
> a proposal/issue/"request to change something" is based on *"rough 
> consensus"* reached among people involved in the mailing list 
> discussion, especially when the reason for accepting or rejecting are 
> based more on philosophical then technical issues.

I must admit to being more interested in technical soundness than 
consensus. However, if we are to base things on consensus, then we need an 
objective definition of consensus, so that it can be determined when we do 
or do not have consensus. Is there such a definition?

> and not from the decision of a single person. I am sorry to notice, 
> following the ml discussion, that a lot of the proposals have been 
> discarded for philosophical reasons even if the majority of the people 
> in the ml were in favour. I am not saying that you should adopt them 
> straight, but only that you should keep open the discussion on 
> controversial issues and seek a sort of consensus, among people involved 
> in the discussion, on how to solve them

I thought that's what I was doing: responding to proposals with counter 
proposals, evaluating arguments on technical merit, and taking part in the 
continuing debates. Surely you are not suggesting that anybody has been 
preventing anyone from continuing the discussions?

On Wed, 28 Oct 2009, Infinity Linden (Meadhbh Hamrick) wrote:
> something like RHTTP or BWTP over WS is a bit of a deal-breaker for me.

Nobody is suggesting stopping work on anything, as far as I am aware.

> i guess there's also no reason now to meet at apachecon next week about 
> WS. i mean, why bother meeting about something you can't change?

"Last call" is not the end of the process. If you have feedback, please 
don't hesitate to send it.

> possible by extending HTTP, so why not just do that?

Could you elaborate on your use case?

WebSocket is a better substrate for bidirectional communication than HTTP 
in some specific ways: the latency involved in having to establish new TCP 
connections for each HTTP message is non-existent in WebSocket, the 
overhead of HTTP headers with each request (leading to 1000:1 
overhead:data ratios when sending simple messages like "the user pressed 
'a'") is minimised in WebSocket (the kilobytes of headers overhead in HTTP 
is reduced to two bytes in WebSocket), and the difficulties on the 
server-side of associating outgoing connections with incoming connections 
is removed (there's only one TCP connection in WebSocket).

What problems are you having that WebSocket _doesn't_ solve, or prevents 
you from solving?

> BASE64 encoded binary blobs with metadata over the connection.

As far as I can tell, the use case of sending occasional large blobs of 
data to the server from the client is already addressed by HTTP (via 
XMLHttpRequest on the client), so I don't think there's a need for Web 
browsers to implement new protocols to support it. However, I have no 
objection to the working group developing a technology to support this.

On Thu, 29 Oct 2009, Greg Wilkins wrote:
> 
> I completely agree with this sentiment.  WS is usable, but provides no 
> significant benefit over HTTP other than a warm philosophical feeling 
> that you are not abusing HTTP, is a little more byte efficient and 
> marginally better latency.

Reducing kilobytes of data to 2 bytes is more than "a little more byte 
efficient", and reducing latency from 150ms (TCP round trip to set up the 
connection plus a packet for the message) to 50ms (just the packet for the 
message) is far more than marginal. In fact, these two factors alone are 
enough to make WebSocket seriously interesting to Google.

> But it is not going to scale for my use-cases because of the connection 
> bloat.

It halves the number of connections relative to current solutions. I would 
hardly characterise one connection per user as bloat -- it's the same 
model used by IMAP, SSH, and IRC, to name but three protocols I'm using 
right now. 

> It's going to break all the load balancers I work with and the SSL 
> offloaders and most other network infrastructure.

Could you elaborate on what requirements your load balancers and SSL 
offloaders have which, if addressed, would lead to WebSocket working with 
them to your satisfaction?

> opportunity of having a service provider API in the browser - so I could 
> intercept standard ws API and transport it over something that would 
> work my use-cases, or inserting layers between app API and transport.

I don't think that's impossible -- as with any browser feature, the first 
step is convincing browser vendors that they should implement such a 
feature. Generally I work the other way around -- I listen to browser 
vendors, then spec what they say they want to implement. But sometimes 
it's possible to convince browser vendors that they want to implement 
something. However, it doesn't matter what the Hybi group does -- browser 
vendors don't automatically implement something the IETF or W3C invent. 
They have to want to implement it.

---

From: Mike Dierken <[email-masked]>
Date: Sat, 31 Oct 2009 20:29:35 -0700

It's good to see progress on messaging technologies for browsers and
other user agents.

I had one small question about "[..] the latency involved in having to
establish new TCP
connections for each HTTP message is non-existent in WebSocket". I
know that you know that persistent HTTP 1.1 connections reduce the
number of times an open/close of a connection would occur, so I was
curious what's actually happening that connections are created for
each request. (Not that I think the answer will or should change
anything to do with WebSockets, just a curiousity sort of thing).