Re: [hybi] Framing take IV

["Thomson, Martin" <[e-mail]>]

Unfortunately, that’s only true if a channel switch were prevented if a fragmented message was being transmitted.

Imagine that an intermediary wants to de-fragment fragmented messages and it sees the interleaved messages from channels A and B:

  Message (fragment), Channel A: Hello
  Message (end), Channel B: Bonjour tout le monde
  Message (end), Channel A: World

The intermediary just stomped on your messages:

  Message (end), Channel A: Hello {Channel B} Bonjour tout le monde
  Message (end), Channel A: World

Now, we could prevent this sort of thing by saying that if you don’t understand all the extensions, don’t touch, but that’s a little antisocial.

--Martin

From: Ian Fette (イアンフェッティ) [mailto:[e-mail]]
Sent: Wednesday, 4 August 2010 2:39 PM
To: Thomson, Martin
Cc: Greg Wilkins; [e-mail]
Subject: Re: [hybi] Framing take IV

On Tue, Aug 3, 2010 at 9:20 PM, Thomson, Martin <[e-mail]<mailto:[e-mail]>> wrote:
[e-mail]<mailto:[e-mail]> writes:
> As far as I can tell, what Jamie proposed is basically equivalent to what I proposed
> in http://www.ietf.org/mail-archive/web/hybi/current/msg02726.html -
I like this proposal.  It got lost in the email noise the first time around.  It's not exactly what Jamie proposes, but it could be made compatible with it.

+-----------------------------------------------+
|frag(1)| ???(1)|opcode(6)| Length(24)          |
+-----------------------------------------------+
|      Extensions (prearranged length)          |
+-----------------------------------------------+
|                     Data                      |
+-----------------------------------------------+

It makes new protocol features transparent to the framing layer.  All you need to do is define a negotiation for the features.

It's a shame that it doesn't work for multiplexing.

Assuming multiplexing is an extension, we could make it work fine. E.g. the multiplexing extension will reserve 8 bits in the extension section, and we're set.

--Martin