Code change:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Related discussion:
text: 5.2.2.6. <del> The "public" response directive overrides certain conditions that would otherwise make a cache unable to store the response. Specifically, see caching.authenticated.responses regarding the use of public in response to a request containing </del> <ins> The "public" response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the constraints of any other response directives present.  In other words, public explicitly marks the response as cacheable.  For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (caching.authenticated.responses). </ins> <del> , and response.cacheability for how public affects responses that would normally not be stored, due to their status codes not being defined as heuristically cacheable; see heuristic.freshness. </del> <ins> If no explicit freshness information is provided, the response is is heuristically cacheable (heuristic.freshness). </ins> 5.2.2.7. Argument syntax: <del> The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared </del> <ins> The unqualified "private" response directive indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user).  It also indicates that a private cache MAY store the response, subject to any other cache directives present, even if the response would not otherwise be heuristically cacheable by a private </ins> cache. <del> If the private response directive specifies one or more field names, this requirement is limited to the field values associated with the listed response header fields.  That is, a shared cache MUST NOT store the specified field names(s), whereas it MAY store the remainder of the response message. </del> <ins> If a qualified private response directive is present, with an argument that lists one or more field names, then only the listed fields are limited to a single user: a shared cache MUST NOT store the listed fields if they are present in the original response, but MAY store the remainder of the response message without those fields. </ins> The field names given are not limited to the set of header fields defined by this specification.  Field names are case-insensitive.