Original text:
An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content coding in <del> response.  If an Accept-Encoding header field is present in a request and none of the available representations for the response have a content coding that is listed as acceptable, the origin server SHOULD send a response without any content coding. </del>  When the Accept-Encoding header field is present in a response, it indicates what content codings the resource was willing to accept in

Reviewer comments:
Should we mention this on the mailing list?
Sure.
specified that identity content-coding could be made unacceptable (e.g., indicating very strong preference for response compression) by means of an Accept-Encoding request header field value like or without an identity-specific preference, and then recommended that the server SHOULD respond with 406 (Not Acceptable) when it cannot send an acceptable response. But and the update that last point to "SHOULD send a response without any content-coding", presumably primarily intended to avoid sending 406 (Not Acceptable) when the acceptability of identity content-coding is unspecified. The text still includes a description of when identity content-coding is unacceptable and still accommodates a "compression is mandatory" interpretation of , but seems to strongly discourage it in the sense of ("there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course"). I suspect this to be unintentional, and would propose clarification in semantics: In the absence of such clarification, the text describing when identity content-coding is unacceptable seems to be largely pointless.
I agree that this is not optimal, but the proposed text would change the protocol from what is has been since RFC 7231. Given that the current draft is approved and in the publication queue, I don't think that a change is possible or even desirable.
The move away from sending 406 was intentional in RFC7231. There is no implementation support for identity;q=0 overriding basic interoperability (200 response without encoding), unlike Accept for unwanted media types, because encodings are often applied late in the request handling process based on the server's analysis of whether they are efficient/possible. Hence, clients simply list the acceptable encodings and variance in the field values cause unwanted cache misses. The feature only made sense for non-compression encodings. This does not prevent a server from responding with 406, but doing so is less interoperable (without some additional knowledge about why the client is asking for that) than sending no encoding.
If it is indeed intentional for absence of content coding to always be considered acceptable, then what is the purpose of keeping (emphasis mine)?
I meant that the move away from 406 was intentional. Suggesting that "identity;q=0" not be respected was not intentional, but is also not implemented AFAIK (It only makes sense for encryption-related encodings). I would suggest a less normative fix, like and just send that now to the RFC editor as a clarification.
Great, thanks!
NAME - are you going to create a PR for this?
LGTM

Revised text:
An Accept-Encoding header field with a field value that is empty implies that the user agent does not want any content coding in  <ins> response.  If a non-empty Accept-Encoding header field is present in a request and none of the available representations for the response have a content coding that is listed as acceptable, the origin server SHOULD send a response without any content coding unless the identity coding is indicated as unacceptable. </ins> When the Accept-Encoding header field is present in a response, it indicates what content codings the resource was willing to accept in