- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 30 Oct 2016 11:35:01 +0100
- To: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2016-10-30 11:22, Martin Thomson wrote: > After discussion about content codings, I've made something of a > drastic change to the encryption draft. A preview is here: > http://httpwg.org/http-extensions/encryption-preview.html > > The pull request is here: > https://github.com/httpwg/http-extensions/pull/252 > > This is a huge simplification in many ways, so I think that's a fair > improvement. > > The main assertion that this assumes is this: content codings should > be self-descriptive. > > Obviously, this isn't a strong assertion given that this content > coding requires a key, and SDCH relies on having an external > dictionary, but the point is that the contents of the message can be > decoded without reading additional header fields. This is consistent > with the observation that James Manger made about the MICE content > coding previously [1]. > > To that end, I've removed the Encryption header field and packed the > critical data into the content itself. This is more efficient and > avoids strange cross-header-field correlation between Encryption and > Content-Encoding. It retains Crypto-Key and key identifiers, but > that's necessary since they generally travel separately. > > I realize that we're close to the draft submission deadline, so I'm > planning to publish the draft with these modifications. We can > continue to have this discussion. Thanks to the magic of revision > control systems, it's easy to revert this change if needed. > > (Yes, this messes with webpush, I still need to talk to people about > what to do there.) > > > [1] https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0242.html +1 in general. That said, doesn't have Crypto-Key a similar problem (in that you might not now what applied encryption content codings it applies to)? Best regards, Julian
Received on Sunday, 30 October 2016 10:35:38 UTC