Ballot for draft-ietf-httpbis-cice
Yes
No Objection
Note: This ballot was opened for revision 02 and is now closed.
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.