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

[Julian Reschke <[e-mail]>]

On 2015-09-03 03:20, Ben Campbell wrote:
> ...
> ----------------------------------------------------------------------
> 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.
> ...

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.

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

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