Re: New Version Notification for draft-vkrasnov-h2-compression-dictionaries-01.txt

Just chiming in without necessarily attaching to a particular thread of
discussion: I'm quite probably being thick here, but isn't there a problem
(of the abstraction/encapsulation flavour) with making a content-encoding
dependent on values sent at the transport layer? I think I'm just
reiterating what Martin was saying, but in a more vague and incoherent way.

If we're discussing compression parameters/algorithms/dictionaries/etc. at
the transport layer, shouldn't the entirety of the compression happen at
the transport layer? Thus making it like HTTP/2's new version of TE.

And if so, isn't transport layer compression a Bad Thing™? Because – thanks
to the wonder of abstraction – the transport machinery doesn't
(necessarily) know the provenance of the bytes it's compressing (thus
potentially allowing sensitive and attacker-controlled data to be
compressed in the same context – i.e. BREACH.)

So we bounce it up the stack to the application, which has a much better
chance of knowing who authored what bytes. And thus we end up back at
content-encoding.

If it's tied to content-encoding, it should be **entirely** contained in
the semantic layer – headers and payload entities. Isn't that what SDCH is?

If it's pushed down to the transport layer, isn't it just an even less safe
version of draft-kerwin-http2-encoded-data? (I said no shared compression
context between different frames, this is about sharing contexts between
completely different *streams*!)

I'm not entirely sure what new thing this particular proposal brings to the
table.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/