Re: #445: Transfer-Codings

On 24 April 2014 14:12,  <K.Morgan@iaea.org> wrote:
> 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.

I don't know what it means to get uncompressed frames interspersed
with compressed frames, if the entire segment is intended to have the
same compression context, that's all.

> 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.

Well, this is the consequence of doing that.  You can avoid the issue
entirely by no supporting compressed frames :)

> 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).

Sorry, I should have made that clearer.  That is what I intended to
imply.  It means that you get C-E equivalent performance if you don't
mix security contexts in the same entity body (and don't segment).
However, it does increase state overheads significantly because it's
not just the single bit, it's an entire compression context that you
carry over between frames.

Received on Thursday, 24 April 2014 21:59:51 UTC