jiebi/TextFlow huggingface dataset:
Original text:
VCHAR H <del> Heuristic Expiration (warn-text) </del> heuristic expiration time M <del> Miscellaneous Persistent Warning (warn-text) Miscellaneous Warning (warn-text) </del> max-age (cache directive) max-stale (cache directive) min-fresh (cache directive)

Reviewer comments:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Revised text:
VCHAR H  heuristic expiration time M  max-age (cache directive) max-stale (cache directive) min-fresh (cache directive)
Original text:
proxy-revalidate (cache directive) public (cache directive) <del> R Response is Stale (warn-text) Revalidation Failed (warn-text) </del> S s-maxage (cache directive) shared cache stale strong validator <del> T Transformation Applied (warn-text) </del> V validator

Reviewer comments:
I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).

Revised text:
proxy-revalidate (cache directive) public (cache directive)  S s-maxage (cache directive) shared cache stale strong validator  V validator
Original text:
6. <del> User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation </del>  retrieved earlier in a session. <del> The freshness model (expiration.model) does not necessarily apply to history mechanisms.  That is, a history mechanism can display a previous representation even if it has expired. </del>  <del> This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store). </del>  7.

Reviewer comments:
Sounds good to me.
Might want to mention the scope of applicability for HTTP caching a bit more carefully, esp. with respect to other caches (esp. in browsers).
I think the best thing to do might be to change to something like "Relationship to Other Caches and History Lists" and expand accordingly.
Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons that can be used to redisplay a representation retrieved earlier in a session. Likewise, some Web browsers implement caching of images and other assets within a page view; they may or may not honor HTTP caching semantics. The requirements in this specification do not necessarily apply to how applications use data after it is retrieved from a HTTP cache. That is, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. This does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache-Control: no-store).

Revised text:
6.  <ins> Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons that can be used to redisplay a representation </ins> retrieved earlier in a session.  <ins> Likewise, some Web browsers implement caching of images and other assets within a page view; they may or may not honor HTTP caching semantics. </ins>  <ins> The requirements in this specification do not necessarily apply to how applications use data after it is retrieved from a HTTP cache. That is, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. This does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache- Control: no-store). </ins> 7.
Original text:
4.3.1. <del> When sending a conditional request for cache validation, a cache sends one or more precondition header fields containing metadata from its stored response(s), which is then compared by recipients to determine whether a stored response is equivalent to a current representation of the resource. </del>  One such validator is the timestamp given in a

Reviewer comments:
Caching : Can the cache send any old entity-tag it has stored for the URL in these headers, or must it only do it for those that can be selected by the incoming request, as per the secondary cache key algorithm? Also, this section uses "selected" in a different meaning; that should probably be changed to avoid confusion.
I think it needs to constrain it to the selected stored responses.
We need to be careful to include the case where an upstream cache (or UA) has sent a conditional request (perhaps with some of its own stored etags) and this cache is forwarding them along.
When sending a conditional request for validation, a cache updates the request it is attempting to satisfy with one or more precondition header fields. These contain validator metadata sourced from the stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource. [rest as before]
Isn't this presuming the validation is part of an upstream request? What if the cache is auto-refreshing stored responses during idle time? Maybe we should define these as separate cases?
When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request using a stored response by copying the method, request-target, and request header fields used for identifying the secondary cache key [ref]. It then updates that request with one or more precondition header fields. These contain validator metadata sourced from stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource.

Revised text:
4.3.1.  <ins> When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request using a stored response by copying the method, request-target, and request header fields used for identifying the secondary cache key caching.negotiated.responses. It then updates that request with one or more precondition header fields.  These contain validator metadata sourced from stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource. </ins> One such validator is the timestamp given in a
Original text:
A client sends an HTTP request to a server in the form of a <del> message, beginning with a request-line that includes a method, URI, and protocol version (request.line), followed by header fields containing request modifiers, client information, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del>  A server responds to a client's request by sending one or more HTTP <del> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase (status.line), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del>  The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> A connection might be used for multiple request/response exchanges, as defined in persistent.connections. </del> Responses (both final and non-final) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the

Reviewer comments:
NAME PTAL.
Client/Server Messaging still is HTTP/1.1-specific. Suggested deletions below: Also, trailers?
Textual reason-phrase is also 1.1 specific.
NAME what's the implication of that? It's already suggested to be deleted.
It wasn't in a previous iteration of your suggestion -- see your edit history. Perhaps we noticed this in parallel?
Ah ;)
Somewhat related is .
This text seems out of place in 3.2 Storing Responses to Authenticated Requests. It also omits .
It seems like it's covered by 4.2.4 pretty completely.

Revised text:
A client sends an HTTP request to a server in the form of a  <ins> message, beginning with a method (methods) and URI, followed by header fields containing request modifiers, client information, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). </ins> A server responds to a client's request by sending one or more HTTP  <ins> messages, each beginning with a success or error code (status.codes), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). A connection might be used for multiple request/response exchanges. </ins> The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier.  Responses (both final and non-final) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the
Original text:
negotiation. This document obsoletes RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC <del> 7615, and portions of RFC 7230. </del>  Editorial Note

Reviewer comments:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Revised text:
negotiation. This document obsoletes RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC  <ins> 7538, RFC 7615, and portions of RFC 7230. </ins> Editorial Note
Original text:
changes being summarized in changes.from.rfc.7230.  The other parts of RFC7230 are obsoleted by "HTTP/1.1 Messaging" Messaging.  This document also obsoletes RFC7231 (see changes.from.rfc.7231), RFC7232 <del> (see changes.from.rfc.7232), RFC7233 (see changes.from.rfc.7233), and RFC7233 (see changes.from.rfc.7235), and RFC7615 (see changes.from.rfc.7615). </del>  1.1.

Reviewer comments:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Revised text:
changes being summarized in changes.from.rfc.7230.  The other parts of RFC7230 are obsoleted by "HTTP/1.1 Messaging" Messaging.  This document also obsoletes RFC7231 (see changes.from.rfc.7231), RFC7232  <ins> (see changes.from.rfc.7232), RFC7233 (see changes.from.rfc.7233), RFC7233 (see changes.from.rfc.7235), RFC7233 (see changes.from.rfc.7538), and RFC7615 (see changes.from.rfc.7615). </ins> 1.1.
Original text:
A client sends an HTTP request to a server in the form of a <del> message, beginning with a request-line that includes a method, URI, and protocol version (request.line), followed by header fields containing request modifiers, client information, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del>  A server responds to a client's request by sending one or more HTTP <del> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase (status.line), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del>  The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> A connection might be used for multiple request/response exchanges, as defined in persistent.connections. </del> Responses (both final and non-final) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the

Reviewer comments:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Revised text:
A client sends an HTTP request to a server in the form of a  <ins> message, beginning with a method (methods) and URI, followed by header fields containing request modifiers, client information, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). </ins> A server responds to a client's request by sending one or more HTTP  <ins> messages, each beginning with a success or error code (status.codes), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). A connection might be used for multiple request/response exchanges. </ins> The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier.  Responses (both final and non-final) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the
Original text:
contains a short hypertext note with a hyperlink to the different URI(s).  9.5. The

Reviewer comments:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Revised text:
contains a short hypertext note with a hyperlink to the different URI(s). <ins> 9.4.9. The status code indicates that the has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.  Clients with link editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible. The server SHOULD generate a header field in the response containing a preferred URI reference for the new permanent URI.  The user agent MAY use the Location field value for automatic redirection.  The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s). A 308 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness). </ins> 9.5. The
Original text:
305 Use Proxy (status code) 306 (Unused) (status code) 307 Temporary Redirect (status code)  3xx Redirection (status code class) 4

Reviewer comments:
Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.

Revised text:
305 Use Proxy (status code) 306 (Unused) (status code) 307 Temporary Redirect (status code) <ins> 308 Permanent Redirect (status code) </ins> 3xx Redirection (status code class) 4
Original text:
authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. <del> A sender MUST NOT generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below). </del>  A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the

Reviewer comments:
I had in mind something a little more general, that would include fields which are defined like Vary:

Revised text:
authentication credentials, or deliberately misleading duplicate header fields that would impact request processing.  <ins> Aside from the well-known exception noted below, a sender MUST NOT generate multiple header fields with the same field name in a message, or append a header field when a field of the same name already exists in the message, unless that field's definition allows multiple field values to be recombined as a comma-separated list [i.e., at least one alternative of the field's definition allows a comma-separated list, such as an ABNF rule of #(values)]. </ins> A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the
Original text:
5.4. <del> The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as </del>  <del> was not defined until HTTP/1.1).  When the Cache-Control header field is also present and understood in a request, Pragma is ignored. </del>  <del> In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients.  This specification deprecates such extensions to improve interoperability. When the header field is not present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see cache-request-directive). When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other request directives at HTTP/1.1 or greater caches.  For example: will constrain HTTP/1.1 and greater caches to serve a response no older than 30 seconds, while precluding implementations that do not understand from serving a cached response. </del>  5.5.

Reviewer comments:
Note that there's one more reference to pragma remaining, but that will be taken care of by .
... is still hanging around, and even less relevant. We still recommend sending it in certain circumstances; can we drop that?
Specifically: [ ] In Constructing Responses from Caches -- although see [ ] In Pragma, "When sending a no-cache request, a client ought to include both the pragma and cache-control directives" [ ] In Pragma, "When the Cache-Control header field is not present in a request, caches must consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present" Proposal: Change s registration status to "obsoleted" Remove requirements relating to it. Retain text explaining its semantics, and note that it's superseded by .
BTW, I'm comfortable doing this because we're getting rid of requirements on request CC anyway -- see .
I have a few editorial changes to suggest here to make it more readable and remove the trailing note, but it is probably easier to commit this as is and we can tweak it later.

Revised text:
5.4.  <ins> The "Pragma" header field was defined for HTTP/1.0 caches, so that clients could specify a "no-cache" request (as </ins>  <ins> was not defined until HTTP/1.1). </ins>  <ins> However, support for Cache-Control is now widespread.  As a result, this specification deprecates Pragma. </ins> 5.5.
Original text:
by a secondary key for the values of the original request's selecting header fields (caching.negotiated.responses).  3. A cache MUST NOT store a response to any request, unless:

Reviewer comments:
For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.

Revised text:
by a secondary key for the values of the original request's selecting header fields (caching.negotiated.responses). <ins> A cache is when it cannot contact the origin server or otherwise find a forward path for a given request.  A disconnected cache can serve stale responses in some circumstances (serving.stale.responses). </ins> 3. A cache MUST NOT store a response to any request, unless: