Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding
draft-ietf-httpbis-cice-03

I've cleared the discuss on the following, since it seems that there is precedent in how HTTP has specified this sort of thing before. But I still think some more explicit guidance on when it's reasonable to send and/or use "Accept-Encoding" in 2XX responses would be helpful.

section 3 says:
"Note that this information is specific to the associated request; the
   set of supported encodings might be different for other resources on
   the same server, and could change over time or depend on other
   aspects of the request (such as the request method)."

.. but then later...

"[...] However,  the header field can also be used to indicate to clients that content
   codings are supported, to optimize future interactions.  For example,
   a resource might include it in a 2xx response when the request
   payload was big enough to justify use of a compression coding, but
   the client failed do so."

This seems to indicate a need for guidance on when the client can reuse the Accept-Encoding value.


-- section 3, 5th paragraph:
For the two SHOULDs and one SHOULD NOT in this paragraph, can you suggest some reasons an implementation of this spec might choose something different?

Like in Ben's review, I wondered about the first two SHOULD in this sentence below. 
If there is a SHOULD, you should either explain the exception, or stress that you want to be compliant with RFC7231.

   Encoding" header field in that response, allowing clients to
   distinguish between content coding related issues and media type
   related issues.  In order to avoid confusion with media type related
   problems, servers that fail a request with a 415 status for reasons
   unrelated to content codings SHOULD NOT include the "Accept-Encoding"
   header field.

Let's continue this discussion in the "Ben Campbell's Discuss on draft-ietf-httpbis-cice-02: (with DISCUSS and COMMENT)" email thread, which goes in the right direction IMO.

- A nice easy read.  Thanks.

- Any reason why this document does not update 7231?

Both me and my Gen-ART reviewer believe that the draft should have an Updates: RFC 7231 header. I do not believe this is discuss-worthy, however, given the vague formalism that we've given to RFC headers of this type.

Thanks for responding to the SecDir review.  I see you are waiting for proposed text and can see if Charlie has some or can propose something.
https://www.ietf.org/mail-archive/web/secdir/current/msg05894.html

Thanks for adding the BREACH stuff.