Re: [hybi] Discontinuation of mux standardizaton in favor of WS/HTTP/2.0

[Tobias Oberstein <[e-mail]>]

Hi Peter

>A simple proposal to support WebSocket API functionality might be something like:
>- HTTP 2.0 HEADERS message already provides the functionality necessary to negotiate a given HTTP 2.0 channel as a "WebSocket" channel along with sending subprotocol, cookies, etc.

Yep.

>- An HTTP 2.0 WEBSOCKET frame type could be used to deliver WebSocket messages. You'd need a FIN flag for the message boundaries, frame boundaries would be just standard HTTP 2.0 frames. No need to repackage or reframe or make a distinction between >"websocket" frames and HTTP 2.0 frames.

Why a separate SPDY frame type? Why not SPDY/DATA frames? After negotiation, the whole SPDY _stream_ will be "messaging" only anyway ..
 
>- Depending on how closely we want HTTP 2.0 WebSockets to match RFC6455 WebSockets additional support could be added.. for example, define the WEBSOCKET frame type's flag bits as follows (full compatibility flag configuration):

>From the goal of W3C WebSocket API only compatibility, the only other information (besides message boundaries) needed in SPDY/DATA frames would be the payload type: UTF8 vs binary.

So the minimum appears to be 2 bits in SPDY/DATA frame headers:

1 bit for MSG_DONE on the last SPDY/DATA frame and
1 bit for MSG_TYPE (UTF8/binary) on the first SPDY/DATA frame that starts a new msg

Am I missing something?

/Tobias