Re: [hybi] Framing Take VI (a compromise proposal)

[Greg Wilkins <[e-mail]>]

John,

I'm just going to cherry pick your words to respond to... because I
don't particularly disagree with most of what you say... but...


On 16 August 2010 23:21, John Tamplin <[e-mail]> wrote:

> Finally, it seems better for intermediaries if the opcodes are generally
> unchanging.  Imagine an intermediary that scans for viruses, important
> intellectual property, etc.  If the frame type remains TEXT/BINARY and any
> mux data is in an extension header, it can completely ignore the extension
> and simply look at the payload data for content it wants to block.

But I don't think we can generally do that.  If the extension changes
the data in anyway (add's headers, compresses it, encodes it etc.)
then the intermediary is probably going to fail in it's attempt to
scan the data.

Also if a text frame is being sent, but a compression extension is
applied, then the contents of the frame would not even be text.
Should the opcode be changed to binary to reflect the content, or left
at text to reflect that it is destined for the text API?

I think if an intermediary does not understand an extension, then it
must ignore all data in an extended frame, so there is no harm sending
it as a extension-data op-coded frame.


> If
> instead a MUX opcode was added and buried inside the MUX payload as a new
> frame type, the intermediary would have to understand the MUX extension in
> order to do anything useful with the message.

It could still forward the message along the connection.

I think that an intermediary that is doing anything with muxed data
has to be MUX aware otherwise it will risk contaminating one channel
with state obtained from another.


> In particular, I would think that per-frame extension data would be a good
> fit for multiplexing, as you would want to be able to attach a channel id to
> each frame.

An extension-data op-code would allow a channel id to be associated
with every extension-data frame, so messages would just have to be
sent using that frame type.  I'm not sure that is a bad restriction
given that I think intermediaries that do not understand MUX should do
nothing with the data other than forward it.

cheers