Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

"Arman Djusupov" <> Thu, 23 May 2013 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DE6D21F8FB3 for <>; Thu, 23 May 2013 02:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7TGQ3UF5KSFP for <>; Thu, 23 May 2013 02:09:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2979B21F9709 for <>; Thu, 23 May 2013 02:09:42 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; t=1369300169; x=1369904969; s=m2048;; c=relaxed/relaxed; v=1; bh=w8W+5FS5Y44bEFwgLskeee57HVQ=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=qMyUwoMtnQ9R0IwFYM5OTDWdnyOtVQvDQBgY8m0q9RM9GHorocNhsRZwU72IxCUGwNN9L2Vb2UX5NjdDNmBxoqzdeqVLOoGtjqNxaqcMzWsYp1yZ3mdhRxnn25FJYAh102WTivYhiIqlzR32jGQDrvnZKMg8PWStTc4n5bspaUhrh6ZFTtP8vAX4KlvoHxjGUxbqHAK8EM+oFhovB0jUaxh4xzA/2Lg6VI6e5YxukE9yZyfD4XJmQTfIb/2+S1IHOpZIb9OtFO8dVBZTP2xjr3sDeNnzswXr/4erq16ZPVT4zPU1ZhljTRtFHniD7nsn1LHnuoYZUR8YNgxlfcAJqw==
Received: from by (Noemax Mail Server) with ASMTP (SSL) id 201305231209274099; Thu, 23 May 2013 12:09:27 +0300
From: "Arman Djusupov" <>
To: "'Joakim Erdfelt'" <>
References: <> <> <> <007501ce56f0$67f74080$37e5c180$> <>
In-Reply-To: <>
Date: Thu, 23 May 2013 12:09:30 +0300
Message-ID: <006201ce5795$3eec24d0$bcc46e70$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01CE57AE.643AE370"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGJbPE/yAcYUaa2Hw/8qx+KPIY2GAJfnsrjAhgTLgECNJFvhgKv1fonmVFvGdA=
Content-Language: en-us
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2013 09:12:58 -0000

Agree on channel slot, header deltas, and simplified extension rules.


Concerning the header deltas we can simplify them by applying the
permessage-deflate compression on the entire control channel# 0. It will be
almost like SPDY header compression, only better as it will be applied on
the entire control channel payload. Since we have the permessage-deflate
spec almost ready why not put it to good use? Compressed or not compressed
the control channel could be a simple flag in mux settings.


With best regards,



From: Joakim Erdfelt [] 
Sent: Wednesday, May 22, 2013 6:33 PM
To: Arman Djusupov
Cc: Takeshi Yoshino;
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket


+1 for simplification.


I'll toss some topics onto the table now:

 * AddChannelRequest - eliminate header deltas

 * AddChannelResponse - eliminate header deltas

 * NewChannelSlot - eliminate the "channel slots" management entirely from
the spec, go back to the earlier, easier to implement, concepts from past

 * Simplify the extension rules.  

     Extensions after initial physical connection are applied only to first
logical channel.

     in AddChannelRequest, extensions provided after the mux extension are
used for logical channels.




Joakim Erdfelt <> <> 

Developer advice, services and support
from the Jetty & CometD experts <>  -


On Wed, May 22, 2013 at 6:29 AM, Arman Djusupov <> wrote:

Sorry, just realized that my message was sent to Takeshi privately by
mistake a few days ago.. (wrong button). It was actually intended for the
list so I am repeating it publicly now:



Obviously continuing to develop a hybi-mux spec for another year or two
doesn't make sense. Taking into account that new specifications are coming
and that HTTP2.0 will probably provide multiplexing for both WebSocket and
HTTP traffic, at  this stage it would only be worth investing development
time in a "simple and ready to go" hybi-mux specification. Maybe if we
simplify the spec to rock bottom simplicity, even sacrificing some features
so that we can conclude it very fast, then maybe vendors might pick it up.
This way we will give to WebSocket its own mux for now, while the HTTPbis
draft might take much longer to form into the final specification. In any
case, hybi-mux must be reviewed and finalized in a very short time, plus it
should be simpler and easier to implement than both SDPY and HTTPbis based


With best regards,



From: [] On Behalf Of
Takeshi Yoshino
Sent: Sunday, May 19, 2013 7:31 AM
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket


I got one comment about this.


He/she suggested that we finish the WebSocket dedicated multiplexing quickly
even by simplifying the spec much e.g. cutting some functionality in it that
would take much time to get consensus, and when HTTP/2.0 is matured, switch
to that.


hybi mailing list