Subject: [hybi] WebSocket: current status and next steps

From: Salvatore Loreto <[email-masked]>
Date: Fri, 8 Jul 2011 11:33:41 +0300

(as chairs)

status:
------
Gabriel and I started the WG last call process for version -07 on April 
25th, 2011 (until May 9th),
since then two new version -08 and -09 have been produced
to address all the comments/discussion received during the WG LC time 
and after

the IESG process requires that once the WG LC is over and the document 
is ready
it has to be submitted to IESG for publication...
so we have asked the IESG to publish it,
I will be the Document Shepherd for it.

(if you are not familiar with the IETF process see: 
http://tools.ietf.org/html/rfc4858#section-3 )

Now we are on the AD evaluation phase:
Peter Saint-Andre is the Application AD responsible for HyBi wg;
(you can check all the information from the tracker:
https://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/ )

In order to address the last, mostly editorials comments/fix we have 
asked the editors to produce
a new version -10 for July 11th

as soon the version -10 is produced we will ask
to start the two weeks broader IESG/IETF last call that involve all the 
IETF community (not only the HyBi wg):
the discussion will happen on the IETF discussion list ([email-masked]):
http://www.ietf.org/list/discussion.html

The idea is to take advantage of the IETF81 meeting in Quebec to discuss 
all the comments received
on version -10

what next:
---------
now that the WebSocket Protocol is stable, it is time to discuss the 
extension that we have put on hold for a while
and decide on what we want to work.
among the others I have in my notes:
     - Multiplexing
     - per Frame deflate extension 
(draft-tyoshino-hybi-websocket-perframe-deflate)
     - Timeout (draft-thomson-hybi-http-timeout)
     - DNS SRV for WebSocket (draft-ibc-websocket-dns-srv)

forgive me and let me know if I forgot something... or there is other 
stuff you think is important to discuss

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Dirkjan Ochtman <[email-masked]>
Date: Fri, 8 Jul 2011 10:48:38 +0200

>     - DNS SRV for WebSocket (draft-ibc-websocket-dns-srv)

For the deflate extension, it seems to me that there's a fair amount
of consensus on this list (in "deflate-stream and masking") that the
deflate-stream extension as specified in draft-09 is suboptimal. Given
that, it seems prudent to exclude it from the WebSocket Protocol spec
for now and await the outcome of the perframe-deflate efforts.

As for DNS SRV, I briefly looked it over and think it would certainly
be nice to specify. I just wonder if it wouldn't make more sense to
put it inside the WebSocket Protocol spec, given the mandatory
machinations required from WebSocket client applications.

Cheers,

Dirkjan

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 8 Jul 2011 12:52:33 +0200

> machinations required from WebSocket client applications.

Hi, the problem with the extensions is that we are speaking mostly
about webbrowsers. So if just a widely used webbrowser in the world
decides not to implement an extension (ie: DNS SRV if approbed) then
WebSocket service providers could not rely on such mechanism.

I suppose the same is true for other extensions (but I'm not sure
about their backwards-compatibility and so). In the case of DNS SRV,
all the clients must implement it. If not, it's like if it does not
exist because no one service provider will want to use DNS SRV knowing
that some known clients cannot use them.

Just wondering. Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Dirkjan Ochtman <[email-masked]>
Date: Fri, 8 Jul 2011 13:05:01 +0200

> WebSocket service providers could not rely on such mechanism.

That was kind of my point (but admittedly poorly expressed): we should
put it in the spec (i.e. not as an extension) instead of specifying it
separately as an extension.

Cheers,

Dirkjan

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 11 Jul 2011 11:26:23 +1000

> for now and await the outcome of the perframe-deflate efforts.

+1