Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-00.txt

From: [email-masked]
Date: Wed, 04 Apr 2012 09:23:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF.

	Title           : A Multiplexing Extension for WebSockets
	Author(s)       : John A. Tamplin
                          Takeshi Yoshino
	Filename        : draft-ietf-hybi-websocket-multiplexing-00.txt
	Pages           : 32
	Date            : 2012-04-04

   The WebSocket Protocol [RFC6455] requires a new transport connection
   for every WebSocket connection.  This presents a scalability problem
   when many clients connect to the same server, and is made worse by
   having multiple clients running in different tabs of the same user
   agent.  This extension provides a way for separate logical WebSocket
   connections to share an underlying transport connection.

   Please send feedback to the [email-masked] mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hybi-websocket-multiplexing-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-websocket-multiplexing-00.txt

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 5 Apr 2012 01:30:20 +0900

Hi all,

Here's the initial version of multiplexing extension spec as HyBi WG item.

Change from tamplin-03
http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03 are:

- rephrasing
-- physical channel -> physical connection
-- logical channel -> logical channel and multiplexed connection
--- logical channel: logical data channels one for exchanging control
information and the others for transferring data for multiplexed connection
--- multiplexed connection: virtual WebSocket connection
-- multiplex control frame -> multiplex control block
-- uncompressed -> identity
-- some other issues pointed out by Greg's comments
- clarified that channel ID is assigned by client side on issuing
AddChannelRequest
- added EncapsulatedControlFrame block not to confuse intermediaries
- added diagrams for each multiplex opcode
- put description of multiplex control blocks into subsections instead of
using the list element
- replaced x-google-mux with mux
- sending a frame before waiting for AddChannelResponse (channel 1 is still
disallowed to do so) is now allowed for multiplexed channels
- added what intermediaries must do
- cite RFC 6455 in AddChannelRequest/Response description
- note about reuse of channel ID
- fail when AddChannelRequest is pointing already active channel ID
- AddChanneResponse with F=1: "Enc is ignored" -> "Enc MUST be identity"