Subject: Ben Campbell's Discuss on draft-ietf-httpbis-cice-02: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 02 Sep 2015 18:20:22 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-httpbis-cice-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cice/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
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?

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2015 10:40:05 +0200

On 2015-09-03 03:20, Ben Campbell wrote:
> ...
> ...

Well, it can be used with caveats mentioned in the first excerpt. The 
client can try, and if the situation *has* changed it will find out.

Note that this isn't different from other similar HTTP features, such as 
the "Allow" and "Accept" header fields.

This goes back to the discussion about whether we are changing HTTP/1.1, 
or whether this is an optional extension (which it is; I don't believe 
we have consensus to make a change here that would make existing 
HTTP/1.1 servers non-compliant).

The intent of this spec is to be eventually in-lined into RFC7231bis; as 
such it might make sense to actually get rid of the first two SHOULDs. 
The SHOULD NOT actually can be a MUST NOT without the risk of making any 
existing server non-compliant which isn't already non-compliant.

"Servers that fail a request due to an unsupported content coding ought 
to respond with a 415 status and ought to include an "Accept-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 MUST 
NOT include the "Accept-Encoding" header field."

Best regards, Julian

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 03 Sep 2015 09:12:38 -0500

On 3 Sep 2015, at 3:40, Julian Reschke wrote:

> Note that this isn't different from other similar HTTP features, such 
> as the "Allow" and "Accept" header fields.

Okay, based on the "allow" and "accept" bit, I will clear the discuss 
(but keep the comment.) I do think some explicit guidance on when it's 
reasonable to send or use the header would be useful. Right now it's 
left for the reader to infer.

> This goes back to the discussion about whether we are changing 
> HTTP/1.1, or whether this is an optional extension (which it is; I 
> don't believe we have consensus to make a change here that would make 
> existing HTTP/1.1 servers non-compliant).

I personally think a MUST in this draft would be expected to apply to 
implementers of this draft, not people who don't implement (or possibly 
even read) it.

>
> The intent of this spec is to be eventually in-lined into RFC7231bis; 
> as such it might make sense to actually get rid of the first two 
> SHOULDs. The SHOULD NOT actually can be a MUST NOT without the risk of 
> making any existing server non-compliant which isn't already 
> non-compliant.
>
> "Servers that fail a request due to an unsupported content coding 
> ought to respond with a 415 status and ought to include an 
> "Accept-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 MUST NOT include the "Accept-Encoding" 
> header field."

Are you proposing to make that change now, or at the point of merging 
into RFC7231bis

Thanks!

Ben.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2015 17:07:58 +0200

> implementers of this draft, not people who don't implement (or possibly

Yes, but we're stating that this spec updates the definition of 
Accept-Encoding and status 415, so it would become a normative HTTP 
requirement (IMHO).

> Are you proposing to make that change now, or at the point of merging

I think we should make this change right now.

Best regards, Julian

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 03 Sep 2015 10:09:35 -0500

> Accept-Encoding and status 415, so it would become a normative HTTP 

Ah, point taken.

> I think we should make this change right now.

That would resolve my comment.

Thanks!

Ben.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 4 Sep 2015 16:36:49 +0200

> That would resolve my comment.

Done in 
<https://github.com/httpwg/http-extensions/commit/2c1dd8dedfa0f2c5f2b4dd90a285816a119a69e8>.

Is everybody ok with that change?

Best regards, Julian