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

[Tobias Oberstein <[e-mail]>]

> Using straight up DATA frames would certainly be an option. I suggest a
> separate frame type because I think the types of flags you would set for
> generic requests (like the HTTP 1.1 requests over HTTP 2.0 transport) would
> be different than the types you would set for the short websocket like
> messages. Take the UTF8/binary flag (or the RFC6455 opcode in the more
> general case) for example, does that make sense for a request for an image?

I agree, MSG_TYPE bit would probably not be useful in general.

> 
> You could argue that you could reinterpret the flags in the DATA frame based
> on whether or not you have negotiated websocket mode but this seems ripe
> for confusion and exactly the point of having a frame type. A frame type lets
> you define what flags mean for that frame type and what the rules for the
> processing of that frame type would be. It also simplifies implementation
> logic that might want to logically switch processing branches on frame type.

However, an implementation would probably want to remember if a SPDY stream ID 
is SPDY/Messaging or not, if just to check that all frames on that stream conform to
SPDY/Messaging requirements: either frame opcode or MSG_TYPE flag, and payload
conformance.

Another consideration are intermediaries: do they want simplified handling (all SPDY/DATA
frames handled alike) or specific handling: SPDY/MESSAGE frame differently.

> 
> ------
> Re: minimum bits
> 
> I definitely agree that as written today only message done, stream done, and
> utf8/binary are necessary. Stream done is present already in the DATA frame
> type. This does seem to ignore the fact that RFC6455 defines 8 data message
> types though and might limit compatibility between the two in the future.

Yep, that's the idea. Ignore other WS opcodes, since those are not exposed in the W3C API
anyway, and compatibility with the latter only was the supposed goal.

There is 1 more API thing: W3C API lets me close a WS with "code" and "reason".

How do would this be mapped?

> That said, I am not really sure yet whether that matters. On one hand, text
> and binary covers quite a few cases and I can't really think of a good use for
> more data types visible at the application/WS API level since applications are
> free via subprotocols/convention to define whatever message types they
> want. On the other hand, "because I can't think of a good use case" doesn't
> seem like a strong argument.

Why not? I think thats a good argument in fact;) If we can't come up with a use case (and
I cannot imagine one also), then why pre-plan for a yet-to-be-imagined chimera?

/Tobias