jiebi/TextFlow huggingface dataset:
Original text:
header fields (or lack thereof) as determining factors while choosing the content for this response. <del> An origin server might send Vary with a list of header fields for two purposes: An origin server SHOULD send a Vary header field when its algorithm for selecting a representation varies based on aspects of the request message other than the method and target URI, unless the variance cannot be crossed or the origin server has been deliberately configured to prevent cache transparency.  For example, there is no need to send the Authorization field name in Vary because reuse across users is constrained by the field definition (field.authorization).  Likewise, an origin server might use Cache- Control response directives (field.cache-control) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching. </del>  13.

Reviewer comments:
Note that this also rephrases the SHOULD requirement, but doesn't change its effect.
As mentioned in ... >Section 12.5.5

Revised text:
header fields (or lack thereof) as determining factors while choosing the content for this response.  <ins> A Vary field containing selecting field names has two purposes: An origin server SHOULD generate a Vary header field on a cacheable response when it wishes that response to be selectively reused for subsequent requests.  Generally, that is the case when the response content has been tailored to better fit the preferences expressed by those selecting header fields, such as when an origin server has selected the response's language based on the request's header field. Vary might be elided when an origin server considers variance in content selection to be less significant than Vary's performance impact on caching, particularly when such variance is already being limited by Cache-Control response directives (field.cache-control). Cached content selection is only improved by Vary if there is some chance that the origin server's selection algorithm might prefer a different representation for the recipient in a subsequent request. For example, there is no need to send the Authorization field name in Vary because reuse of that response for a different user is prohibited by the field definition (field.authorization).  Likewise, if the response content has been selected by network region but the origin server wants the cached response to be reused even if recipients move from one region to another, then there is no need for the origin server to indicate such variance in Vary. </ins> 13.
Original text:
more than one member, or if the request method is neither GET nor HEAD.  A recipient MUST interpret an If-Modified-Since field value's timestamp in terms of the origin server's clock.

Reviewer comments:
From : without a concept of modification time. (Section 13.1.4) I couldn't really locate which text was supposed to be providing this clarification.
Re: Appendix B.4 -- This text originally referred to the resolution of , but that was subsequently overwritten when we aligned the way we specified conditionals. It probably needs to be re-introduced (and perhaps looked at for the other conditionals).

Revised text:
more than one member, or if the request method is neither GET nor HEAD. <ins> A recipient MUST ignore the If-Modified-Since header field if the resource does not have a modification date available. </ins> A recipient MUST interpret an If-Modified-Since field value's timestamp in terms of the origin server's clock.
Original text:
received field value is not a valid HTTP-date (including when the field value appears to be a list of dates).  A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.

Reviewer comments:
From : without a concept of modification time. (Section 13.1.4) I couldn't really locate which text was supposed to be providing this clarification.
Re: Appendix B.4 -- This text originally referred to the resolution of , but that was subsequently overwritten when we aligned the way we specified conditionals. It probably needs to be re-introduced (and perhaps looked at for the other conditionals).

Revised text:
received field value is not a valid HTTP-date (including when the field value appears to be a list of dates). <ins> A recipient MUST ignore the If-Unmodified-Since header field if the resource does not have a modification date available. </ins> A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.
Original text:
When an "http" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the host identifier to an IP address, establishing a TCP connection to <del> that address on the indicated port, and sending an HTTP request message to the server containing the URI's identifying data. </del>  If the server responds to such a request with a non-interim HTTP response message, as described in status.codes, then that response is

Reviewer comments:
In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.

Revised text:
When an "http" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the host identifier to an IP address, establishing a TCP connection to  <ins> that address on the indicated port, and sending over that connection an HTTP request message containing a request target that matches the client's target URI (target.resource). </ins> If the server responds to such a request with a non-interim HTTP response message, as described in status.codes, then that response is
Original text:
host identifier to an IP address, establishing a TCP connection to that address on the indicated port, securing the connection end-to- end by successfully initiating TLS over TCP with confidentiality and <del> integrity protection, and sending an HTTP request message over that connection containing the URI's identifying data. </del>  If the server responds to such a request with a non-interim HTTP response message, as described in status.codes, then that response is

Reviewer comments:
In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.

Revised text:
host identifier to an IP address, establishing a TCP connection to that address on the indicated port, securing the connection end-to- end by successfully initiating TLS over TCP with confidentiality and  <ins> integrity protection, and sending over that connection an HTTP request message containing a request target that matches the client's target URI (target.resource). </ins> If the server responds to such a request with a non-interim HTTP response message, as described in status.codes, then that response is
Original text:
used to satisfy the request.  Proxy configuration is implementation- dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually <del> identified by an "http" or "https" URI.  If a proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy. </del>  7.3.3. If no proxy is applicable, a typical client will invoke a handler <del> routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource.  How that is accomplished is dependent on the target URI scheme and defined by its associated specification. </del>  7.4.

Reviewer comments:
In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.

Revised text:
used to satisfy the request.  Proxy configuration is implementation- dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually  <ins> identified by an "http" or "https" URI. If an "http" or "https" proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy and then sending it an HTTP request message containing a request target that matches the client's target URI. </ins> 7.3.3. If no proxy is applicable, a typical client will invoke a handler  <ins> routine (specific to the target URI's scheme) to obtain access to the identified resource.  How that is accomplished is dependent on the target URI scheme and defined by its associated specification. http.origin defines how to obtain access to an "http" resource by establishing (or reusing) an inbound connection to the identified origin server and then sending it an HTTP request message containing a request target that matches the client's target URI. https.origin defines how to obtain access to an "https" resource by establishing (or reusing) an inbound secured connection to an origin server that is authoritative for the identified origin and then sending it an HTTP request message containing a request target that matches the client's target URI. </ins> 7.4.
Original text:
(appointed by the IESG or their delegate).  Fields with the status 'permanent' are Specification Required (RFC8126). <del> Registration requests consist of at least the following information: </del>  And, optionally:

Reviewer comments:
For
Registration requests consist of at least the following information: [...] Specification document(s): Reference to the document that specifies the field, preferably If the registration consists of "at least" a group of information that includes a specification document, doesn't that mean the policy is always "Specification Required", not just for permanent registrations?
I think the intent here was to encourage but not require a specification for provisional registration. Will PR.

Revised text:
(appointed by the IESG or their delegate).  Fields with the status 'permanent' are Specification Required (RFC8126).  <ins> Registration requests consist of the following information: </ins> And, optionally:
Original text:
configuration, it will appear as if Proxy-Authentication-Info is being forwarded because each proxy will send the same field value.  12. When responses convey content, whether indicating a success or an

Reviewer comments:
This goes back to URL
Simplest possible fix would be to mark it as allowed in trailers as well.

Revised text:
configuration, it will appear as if Proxy-Authentication-Info is being forwarded because each proxy will send the same field value. <ins> Proxy-Authentication-Info can be sent as a trailer field (trailer.fields) when the authentication scheme explicitly allows this. </ins> 12. When responses convey content, whether indicating a success or an
Original text:
When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not fresh, or <del> one cannot be selected; see caching.negotiated.responses), it can use </del>  the conditional request mechanism (preconditions) in the forwarded <del> request to give the next inbound server an opportunity to select a </del>  valid stored response to use, updating the stored metadata in the process, or to replace the stored response(s) with a new response. This process is known as

Reviewer comments:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Revised text:
When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not fresh, or  <ins> one cannot be chosen; see caching.negotiated.responses), it can use </ins> the conditional request mechanism (preconditions) in the forwarded  <ins> request to give the next inbound server an opportunity to choose a </ins> valid stored response to use, updating the stored metadata in the process, or to replace the stored response(s) with a new response. This process is known as
Original text:
response, as per constructing.responses.from.caches, the cache SHOULD evaluate any applicable conditional header field preconditions received in that request with respect to the corresponding validators <del> contained within the selected response. </del>  A cache MUST NOT evaluate conditional header fields that only apply to an origin server, occur in a request with semantics that cannot be

Reviewer comments:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Revised text:
response, as per constructing.responses.from.caches, the cache SHOULD evaluate any applicable conditional header field preconditions received in that request with respect to the corresponding validators  <ins> contained within the stored response. </ins> A cache MUST NOT evaluate conditional header fields that only apply to an origin server, occur in a request with semantics that cannot be
Original text:
header field (field.if-none-match) indicates that the client wants to validate one or more of its own stored responses in comparison to the <del> stored response selected by the cache (as per </del>  constructing.responses.from.caches). If an

Reviewer comments:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Revised text:
header field (field.if-none-match) indicates that the client wants to validate one or more of its own stored responses in comparison to the  <ins> stored response chosen by the cache (as per </ins> constructing.responses.from.caches). If an
Original text:
header field and the <del> header field is not present in a selected stored response, a cache SHOULD use the stored response's </del>  field value (or, if no Date field is present, the time that the stored response was received) to evaluate the conditional.

Reviewer comments:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Revised text:
header field and the  <ins> header field is not present in a stored response, a cache SHOULD use the stored response's </ins> field value (or, if no Date field is present, the time that the stored response was received) to evaluate the conditional.
Original text:
A cache that implements partial responses to range requests, as defined in field.range, also needs to evaluate a received <del> header field (field.if-range) regarding its selected stored response. </del>  When a cache decides to forward a request to revalidate its own stored responses for a request that contains an

Reviewer comments:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Revised text:
A cache that implements partial responses to range requests, as defined in field.range, also needs to evaluate a received  <ins> header field (field.if-range) with respect to the cache's chosen response. </ins> When a cache decides to forward a request to revalidate its own stored responses for a request that contains an
Original text:
updating with the new information provided, and then do so. The initial set of stored responses to update are those that could <del> have been selected for that request -- i.e., those that meet the </del>  requirements in constructing.responses.from.caches, except the last requirement to be fresh, able to be served stale or just validated.

Reviewer comments:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Revised text:
updating with the new information provided, and then do so. The initial set of stored responses to update are those that could  <ins> have been chosen for that request -- i.e., those that meet the </ins> requirements in constructing.responses.from.caches, except the last requirement to be fresh, able to be served stale or just validated.
Original text:
receives a response, the cache SHOULD update or invalidate each of its stored <del> GET responses that could have been selected for that request (see </del>  caching.negotiated.responses). <del> For each of the stored responses that could have been selected, if the stored response and HEAD response have matching values for any </del>  received validator fields ( and

Reviewer comments:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Revised text:
receives a response, the cache SHOULD update or invalidate each of its stored  <ins> GET responses that could have been chosen for that request (see </ins> caching.negotiated.responses).  <ins> For each of the stored responses that could have been chosen, if the stored response and HEAD response have matching values for any </ins> received validator fields ( and
Original text:
S s-maxage (cache directive) <del> selected response </del> shared cache stale

Reviewer comments:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Revised text:
S s-maxage (cache directive)  shared cache stale