- From: <K.Morgan@iaea.org>
- Date: Thu, 24 Apr 2014 21:12:37 +0000
- To: <martin.thomson@gmail.com>
- CC: <jgraettinger@chromium.org>, <mnot@mnot.net>, <ietf-http-wg@w3.org>, <matthew@kerwin.net.au>
On Apr 24, 2014, at 22:07, "martin.thomson@gmail.com" <martin.thomson@gmail.com> wrote: > On 24 April 2014 12:58, <K.Morgan@iaea.org> wrote: >> ... i.e. would it be an error to have the compress flag vary from frame to frame within a segment? ...> > Yes, I think that it would have to be an error to toggle the COMPRESSED flag for a segment. Why do you think it would have to be an error? (I'm not disagreeing, just want to understand the reasoning.) Would it introduce a security vulnerability? Increase implementation complexity? Although it might be odd for an implementation to mix compressed and uncompressed frames within a segment, I can think of examples where it might be convenient. As I said, checking for this error condition would force the receiver to track the state of the COMPRESSED flag for the current segment of all outstanding streams - and the only reason for the state would be to detect the toggling error condition. It also essentially makes the COMPRESSED flag redundant from frame to frame because only the value of the flag in the first frame of the segment would count. If you're going to impose a requirement on the receiver to track this state for all streams, then you might as well change from per frame compression to per segment compression. Per segment compression would improve the compression factor. It would also be more compatible with T-E from 1.1 (eg at 1.1 <-> 2 gateways). I'm not actually advocating for per segment compression. I like the simplicity of per frame compression (particularly the statelessness). -Keith This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Thursday, 24 April 2014 21:14:42 UTC