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

["Ben Campbell" <[e-mail]>]

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

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

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.

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

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.