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

From: [email-masked]
Date: Wed, 19 Sep 2012 22:47:18 -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-06.txt
	Pages           : 41
	Date            : 2012-09-19

Abstract:
   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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-multiplexing

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-multiplexing-06

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

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 20 Sep 2012 15:09:46 +0900

No semantic change.

- Added "Number Encoding in Multiplex Control Blocks" section. Though
length encoding is almost the same as WebSocket core spec, we need some
additional texts to define error handling.
- Gave a name "logical channel ID tag" to the logical channel ID at the
head of encapsulating message to distinguish it from logical channel IDs in
multiplex control blocks
- Moved texts explaining error handling that is applied to both control and
non-control channel to section 7 "Framing"
- Added notes like "unless _Fail the Physical Connection_ is already done
for any other error" so that implementors can choose flexibly at which
point they stop processing multiplex control frame with error
- Clarified that
-- minimal number of bytes MUST be used for channel ID encoding
-- when a server received NewChannelSlot or AddChannelResponse, it MUST
fail the physical connection
-- when a client received AddChannelRequest, it MUST fail the physical
connection
-- RSV bits in multiplex control blocks must be 0
-- replying to AddChannelRequest may be delayed
-- if fallback bit is raised in a NewChannelSlot, the other fields MUST be 0

Takeshi

On Thu, Sep 20, 2012 at 2:47 PM, <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>