- From: Ben Campbell <ben@nostrum.com>
- Date: Thu, 03 Sep 2015 10:09:35 -0500
- To: "Julian Reschke" <julian.reschke@greenbytes.de>
- Cc: "The IESG" <iesg@ietf.org>, "Mark Nottingham" <mnot@pobox.com>, ietf-http-wg@w3.org
On 3 Sep 2015, at 10:07, Julian Reschke wrote: > On 2015-09-03 16:12, Ben Campbell wrote: >> On 3 Sep 2015, at 3:40, Julian Reschke wrote: >> ... >>> 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. > > 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). Ah, point taken. > >>> 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 > > I think we should make this change right now. That would resolve my comment. Thanks! Ben.
Received on Thursday, 3 September 2015 15:10:14 UTC