- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 19 Oct 2016 08:11:16 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP working group mailing list <ietf-http-wg@w3.org>, Patrick McManus <pmcmanus@mozilla.com>
Thanks for the changes, Martin! On 2016-10-19 06:13, Martin Thomson wrote: > ... >> I believe we need to clarify the precise interaction between new content >> codings and this header field. I'll assume any new content coding needs to >> opt-in to use this field value as well, so it's clear how to remove entries >> when unwrapping codings. > > I think that I have some text that will help. I think that the answer is: > > Content codings that use the Encryption header field MUST always include a > value for the header field when the content coding has been applied. If no > parameters are needed, then a dummy value is necessary to avoid confusion about > which set of parameters applies to which content coding. This requirement > applies to uses of the `aesgcm` content coding, which does not need a dummy > value because the `salt` parameter is mandatory. > [97b3c12] and [67b65df] > ... "applies" -> "does not apply"? In any case: this sounds like a band-aid. I think it would be good to discuss the whole parametrization of content codings... > ... >> Might be better to cite the slightly newer >> <https://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/>. In any case, please >> add the W3C short name to the series element, such as in: > [8ea4739] > > Interesting thing I learned from this: there are rules for "fixing" > non-ASCII names in xml2rfc. > ... But they are unreliable... Best regards, Julian
Received on Wednesday, 19 October 2016 06:12:06 UTC