Subject: [hybi] New charter for HyBi wg

From: Salvatore Loreto <[email-masked]>
Date: Wed, 18 Jan 2012 16:21:13 +0100

Hi there,

as you know
the WebSocket Protocol has been published on December 2011 as RFC 6455.

Thanks again to all of you for all your technical and editorial contributions to the design of the protocol.

Now having completed the work on the core protocol, we are ready as a group to continue the discussion
to define extensions for use by WebSocket implementations.

Gabriel and I have worked on a draft of the new charter for the HyBi wg that is focused
on the main extensions that have already been discussed by the WG last year.
(See the charter below)

Please let we know your opinion on the draft.
All the feedback, suggestions and proposal are really welcome.

New Charter
------------------

Description of Working Group:

    The BiDirectional or Server-Initiated HTTP (HyBi) working group defines the WebSocket Protocol,
a technology for bidirectional communication between an HTTP client and an HTTP server that provides
greater efficiency than previous approaches (e.g., use of hanging requests or long polling).

    Having completed work on the core protocol (RFC 6455), the group continues to define extensions for
use by WebSocket implementations. The following extensions and optimizations are currently in scope:

    1. Define a per-frame compression extension to improve the bandwidth usage.

    2. Define a multiplexing extension to improve the scalability of the WebSocket protocol

    3. Define timeout-handling capabilities to reduce the chattiness of the protocol

    The working group will also serve as a discussion forum for subprotocols.
However, no subprotocol is currently chartered as official WG item.

    The HyBi working group will continue its liaison with the W3C WepApps working group with respect
to the above deliverables and to ensure the best match possible between the WebSocket protocol and
the WebSocket API. The WG will also continue coordinating with other WGs within the IETF (e.g., HTTPbis)
as appropriate.

    Goal and Milestones:

    May 2012 - Issue WG last call on the per-frame compression extension

    Jun 2012 - Send per-frame compression extension to IESG for publication as Proposed Standard

    Aug 2012 - Issue WG last call on timeout handling

    Sep 2012 - Issue WG last call on the multiplexing extension

    Oct 2012 - Send timeout handling to IESG for publication as Proposed Standard

    Nov 2012 - Send Multiplexing extension to IESG for publication as Proposed Standard

best regards
Salvatore Loreto
www.sloreto.com

---

From: John Tamplin <[email-masked]>
Date: Fri, 20 Jan 2012 07:45:04 -0500

> All the feedback, suggestions and proposal are really welcome.

This sounds fine to me -- from the sequence of milestones, I assume we
would be working on these serially rather than in parallel, is that right?

Regarding the dates, I think they are fine as a target, but I think it is
likely to change as we start the discussions.  Also, given the timeline of
the base spec the dates seem perhaps optimistic :).

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Jan 2012 16:21:14 +0000

Hi John,

On 20/01/2012 12:45, John Tamplin wrote:
  [...]
> would be working on these serially rather than in parallel, is that right?

In general this is up to the WG chairs. They may or may not allow for 
some level of parallel processing. But the main idea is to concentrate 
on things listed first.
> Regarding the dates, I think they are fine as a target, but I think it 
> is likely to change as we start the discussions.  Also, given the 
> timeline of the base spec the dates seem perhaps optimistic :).

They might be optimistic, but they can be adjusted later on.

---

From: Jesse McConnell <[email-masked]>
Date: Fri, 20 Jan 2012 12:14:46 -0600

Is it safe to assume that the starting place for the mux extension
will be John's google-mux draft?  If so, would it make sense to start
off the extensions discussions there, or does it make more sense to
work on some 'official' simple extensions before tackling that more
complex one?  I am a bit torn on where it would be best to start.  I
would like to see the mux 'official' as soon as possible but I am
unclear if individual extensions could have much of an effect on the
mux extension or vis versa.

Just curious as he has some nice work done there which could be a nice
starting point.

cheers,
jesse

--
jesse mcconnell
[email-masked]

On Fri, Jan 20, 2012 at 10:21, Alexey Melnikov
<[email-masked]> wrote:
> In general this is up to the WG chairs. They may or may not allow for some
> level of parallel processing. But the main idea is to concentrate on things
> listed first.
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: John Tamplin <[email-masked]>
Date: Fri, 20 Jan 2012 14:35:51 -0500

> Just curious as he has some nice work done there which could be a nice

If someone has an alternate proposal, that is fine, but in the absence of
that I suggest http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-01 is
as good a place to start as any.

I suspect per-frame compression will be easier to get agreement on, and so
could be completed more quickly.  There is a pressing need for both, but
shortest-job-first scheduling gets something useful deployed faster.

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 20 Jan 2012 19:56:10 +0000

Yes, the assumption is that multiplexing will use John’s draft as a starting point, and the compression will use Takeshi’s draft as a starting point. I agree that the compression extension is better understood and more contained, which is why it is targeted as finishing earlier, although some parallel work might be ok as one tapers off. We can always modify dates and estimates later on, but this is just a first stab.

I agree that the mux extension is more complex and invite discussion as to how the WG sees it and whether the currently proposed milestones are within the ballpark (it’s ok for them to be somewhat optimistic, as were our original charter’s milestones).

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Tamplin
Sent: 20 January, 2012 11:36
To: Jesse McConnell
Cc: [email-masked]
Subject: Re: [hybi] New charter for HyBi wg

On Fri, Jan 20, 2012 at 1:14 PM, Jesse McConnell <[email-masked]<mailto:[email-masked]>> wrote:

If someone has an alternate proposal, that is fine, but in the absence of that I suggest http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-01 is as good a place to start as any.

I suspect per-frame compression will be easier to get agreement on, and so could be completed more quickly.  There is a pressing need for both, but shortest-job-first scheduling gets something useful deployed faster.

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 23 Jan 2012 13:33:26 +0900

I'm fine with the plan.

Takeshi

On Sat, Jan 21, 2012 at 04:56, Gabriel Montenegro <
[email-masked]> wrote:

>  Yes, the assumption is that multiplexing will use John’s draft as a
> starting point, and the compression will use Takeshi’s draft as a starting
> point. I agree that the compression extension is better understood and more
> contained, which is why it is targeted as finishing earlier, although some
> parallel work might be ok as one tapers off. We can always modify dates and
> estimates later on, but this is just a first stab.****
>
> ** **
>
> I agree that the mux extension is more complex and invite discussion as to
> how the WG sees it and whether the currently proposed milestones are within
> the ballpark (it’s ok for them to be somewhat optimistic, as were our
> original charter’s milestones).****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *John Tamplin
> *Sent:* 20 January, 2012 11:36
> *To:* Jesse McConnell
> *Cc:* [email-masked]
> *Subject:* Re: [hybi] New charter for HyBi wg****
>
> ** **
>
> On Fri, Jan 20, 2012 at 1:14 PM, Jesse McConnell <
> [email-masked]> wrote:****
>
> starting point.****
> ** **
> as good a place to start as any.****
>
> ** **
>
> shortest-job-first scheduling gets something useful deployed faster.****
>
> ** **
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google****
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 23 Jan 2012 21:05:33 -0700

<hat type='AD'/>

> All the feedback, suggestions and proposal are really welcome.

I'm encouraged by the positive response so far. If no one raises
significant concerns by the end of the week, I will introduce this topic
during the IESG telechat on February 2.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/