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

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot discuss]
This should be easy to resolve, but I want to make sure there's been thought on it:

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.

[Ballot comment]
-- 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?

[Ballot comment]
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

[Ballot comment]
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.

[Ballot discuss]


Did anyone think through the potential for this kind of
change to interact with attacks like BREACH? [1] It
looks like at least some of the mitigations mentioned on
[1] would not apply to requests, or possibly not, so I
suspect there is something to say here. If that analysis
was not done, I think someone ought look at it. If that
analysis was done, shouldn't there be some mention here?

  [1] http://breachattack.com/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-cice-01.  Please report any inaccuracies as soon as possible.

IANA's reviewer has the following comments:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the "Permanent Message Header Field Names" sub-registry of the Message Headers registry located at:

http://www.iana.org/assignments/message-headers

the entry for the "Accept-Encoding" header field is to be updated as follows:

Header Field Name: Accept-Encoding
Protocol: http
Status: standard
Reference: [RFC7231], Section 5.3.4; [ RFC-to-be ], Section 3

As this is an Expert Review registry, we have asked for and received the expert's confirmation that this change can be made.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- 'Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-08-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  In HTTP, content codings allow for payload encodings such as for
  compression or integrity checks.  In particular, the "gzip" content
  coding is widely used for payload data sent in response messages.

  Content codings can be used in request messages as well, however
  discoverability is not on par with response messages.  This document
  extends the HTTP "Accept-Encoding" header field for use in responses,
  to indicate that content codings are supported in requests.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cice/

IESG discussion, once it begins, can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cice/ballot/

No IPR declarations have been submitted directly on this I-D.

1. Summary

Mark Nottingham is the document shepherd; Barry Leiba is the responsible
Area Director.

In HTTP, content codings allow for payload encodings such as for
compression or integrity checks. In particular, the "gzip" content
coding is widely used for payload data sent in response messages.

Content codings can be used in request messages as well, however
discoverability is not on par with response messages. This document
extends the HTTP "Accept-Encoding" header field for use in responses, to
indicate that content codings are supported in requests.

2. Review and Consensus

This document was discussed at a few meetings, as well as on the list.
It was reviewed by a number of people, and a few different designs were
discussed early in its lifetime before we settled on the current design.

There is not currently any known implementation; this document is
"filling a hole" in HTTP, and we have seem some interest from
implementers and deployers of HTTP.

3. Intellectual Property

Julian has confirmed that to his direct, personal knowledge, there is no
IPR related to this document.

4. Other Points

This document does not contain any downrefs, and its IANA
considerations are clear.

# Shepherd Writeup for draft-ietf-httpbis-cice

## 1. Summary

Mark Nottingham is the document shepherd; Barry Leiba is the responsible Area Director.

In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.

Content codings can be used in request messages as well, however discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate that content codings are supported in requests.

## 2. Review and Consensus

This document was discussed at a few meetings, as well as on the list. It was reviewed by a number of people, and a few different designs were discussed early in its lifetime before we settled on the current design.

There is not currently any known implementation; this document is "filling a hole" in HTTP, and we
have seem some interest from implementers and deployers of HTTP.

## 3. Intellectual Property

Julian has confirmed that to his direct, personal knowledge, there is no IPR related to this document.

## 4. Other Points

This document does not contain any downreferences, and its IANA considerations are clear.