W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: 2nd Working Group Last Call: draft-ietf-httpbis-encryption-encoding-03.txt

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>
Message-ID: <90ee7958-5697-23ad-6f52-060f58800067@gmx.de>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 19 October 2016 06:12:09 UTC