Subject: [hybi] alternative frame encoding proposal

From: Scott Ferguson <[email-masked]>
Date: Thu, 04 Mar 2010 20:02:36 -0800

A strawman for discussion purposes.

A. Properties of the proposal:

  1. supports current browser API

  2. supports binary efficiently

  3. easy to implement senders and receivers

  4. integrates well with more sophisticated sub-protocols, including 
higher-layer multiplexing/flow-control protocols

B. Definitions:

 "sub-protocol" - the higher-layer protocol which consumes the frames 
from web sockets, either a formal protocol like a multiplexing protocol, 
or the application itself viewed as a protocol layer.

 "frame" - a semantically meaningful sequence used by the sub-protocol, 
<length,data> i.e. the sub-protocol can rely on the length being 
preserved by the origin server or any web-socket intermediaries.

 "chunk" - a length-encoded sequence of bytes split for buffering 
purposes (i.e. no semantic meaning). The chunk is not visible to the 
sub-protocol, and the origin servers or intermediaries may combine and 
split chunks as desired.

 "message" - a higher-level entity with meaning only to the 
sub-protocol, i.e. not defined by this protocol. A multiplexing 
sub-protocol might break its message into frames and order and 
prioritize, delay, etc, the frames. The browser sub-protocol would 
identify message == utf-8 decoding of the frame bytes.

C. Sub-protocol negotiation:

  1. The sub-protocol is negotiated through the HTTP headers, including 
the encoding to frame bytes. For example, the "browser-text" 
sub-protocol encodes its text message into a web sockets frame using utf-8.

  2. as above, the message's encoding to the frame bytes is determined 
by the sub-protocol

D. Grammar:

  stream ::= frame*

  frame ::= (non-terminal-chunk)* terminal-chunk

  terminal-chunk ::= NN NN byte{NNNN}
      where 0 <= NNNN <= 0x7fff

  non-terminal-chunk ::= NN NN byte{NNNN & 0x7fff}
     where 0x8000 <= NNNN <= 0xffff

(i.e. NN NN is network byte order, high bit is terminal/non-terminal, 
lower 15 bits are the chunk length.)

Frames are delivered in the order sent. (While a web socket proxy could 
not change the order, a sub-protocol proxy could reorder frames, route, 
merge into messages, etc, according to the rules of the sub-protocol.)

--- this ends the normative section

E. Multiplexing and flow-control sub-protocol discussion (non-normative)

Any multiplexing/flow-control sub-protocol will use extra bytes to 
encode the flow commands, channel identifier, message fragment 
identifier, etc. This web sockets proposal does not pre-allocate any 
bits for those purposes under the theory that the sub-protocol knows 
best its own encoding.

 From an encoding-efficiency standpoint, it doesn't matter if a frame is 
encoded like

  flow-code NN NN data
vs
  NN NN flow-code data

It's the same number of bytes, but the second encoding gives more 
control to the sub-protocol.

-- Scott