jiebi/TextFlow huggingface dataset:
Original text:
its own resources needs to be able to parse and process those same references when received as a target URI.  2.4. A recipient MUST interpret a received protocol element according to

Reviewer comments:
This MUST is very fuzzy, and obviously isn't testable. Should it just be prose?
Not convinced, but wouldn't object. Maybe "needs to"?
That's what makes the ABNF normative. I don't see a need to change it now.
Sorry, what does the ABNF have to do with this? The issue is the phrase "MUST be able to parse any value of reasonable length", where "reasonable length" is not defined.
It is defined as being reasonable. I have no problem testing that (subjectively). ;-)
I meant the second half.
How about
I like it

Revised text:
its own resources needs to be able to parse and process those same references when received as a target URI. <ins> Many received protocol elements are only parsed to the extent necessary to identify and forward that element downstream.  For example, an intermediary might parse a received field into its field name and field value components, but then forward the field without further parsing inside the field value. </ins> 2.4. A recipient MUST interpret a received protocol element according to
Original text:
likely intended for some other (inbound) server. The proper evaluation of conditional requests by a cache depends on <del> the received precondition header fields and their precedence, as defined in precedence.  The </del>  and <del> conditional header fields are not applicable to a cache. </del>  A request containing an

Reviewer comments:
There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.

Revised text:
likely intended for some other (inbound) server. The proper evaluation of conditional requests by a cache depends on  <ins> the received precondition header fields and their precedence.  In summary, the </ins> and  <ins> conditional header fields are not applicable to a cache, and takes precedence over . See precedence for a complete specification of precondition precedence. </ins> A request containing an
Original text:
The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements <del> for that response's status code.  A cache MUST NOT store a response containing the must-understand directive if the cache does not understand the response status code. </del>  5.2.2.3.

Reviewer comments:
There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.

Revised text:
The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements  <ins> for that response's status code. Responses containing "must-understand" SHOULD also contain the "no- store" directive; caches that implement "must-understand" SHOULD ignore the "no-store" directive in responses that contain both directives and a status code that the cache understands and conforms to any related caching requirements. </ins> 5.2.2.3.
Original text:
obey this directive, and communications networks might be vulnerable to eavesdropping.  5.2.2.5. The "no-transform" response directive indicates that an intermediary

Reviewer comments:
There's still a difference when the response mixes strong and weak validators, right? If both types are present, the weak ones would get ignored. Is that intentional?
Yes, that is intentional.
is silent about what to do when there's more than one validator in the message. Freshening responses with HEAD (just below) specifies that any validators must match. (use of 'match' there is a bit fuzzy, should probably link to where it's defined)
I think this section would be better written in terms of entity tags and dates, rather than the abstract notion of strong validators. But I don't know if we have time for that. The basic idea is that a cache might have sent several strong validators in the request and is now being told that at least some of those validators indicate valid responses, so each validator in the 304 indicates a valid response. I don't think the origin server has a preference on which one, but in general the strong etag validators should be considered first.

Revised text:
obey this directive, and communications networks might be vulnerable to eavesdropping. <ins> Note that the "must-understand" cache directive overrides "no-store" in certain circumstances; see cache-response-directive.must- understand. </ins> 5.2.2.5. The "no-transform" response directive indicates that an intermediary
Original text:
representation. For example, a browser might decode the content coding of a response <del> payload while it is being received, creating a disconnect between the data it has stored and the response payload's original metadata. Updating that stored metadata with a different </del>  header field would be problematic.  Likewise, a browser might store a <del> post-parse tree representation of HTML, rather than the payload </del>  received in the response; updating the header field would not be workable in this case, because any

Reviewer comments:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Revised text:
representation. For example, a browser might decode the content coding of a response  <ins> while it is being received, creating a disconnect between the data it has stored and the response's original metadata.  Updating that stored metadata with a different </ins> header field would be problematic.  Likewise, a browser might store a  <ins> post-parse tree representation of HTML, rather than the content </ins> received in the response; updating the header field would not be workable in this case, because any
Original text:
A response's age can be calculated in two entirely independent ways: <del> These are combined as </del>  <del> unless the cache is confident in the value of the header field (e.g., because there are no HTTP/1.0 hops in the header field), in which case the corrected_age_value MAY be used as the corrected_initial_age. </del>  The current_age of a stored response can then be calculated by adding the time (in seconds) since the stored response was last validated by

Reviewer comments:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Revised text:
A response's age can be calculated in two entirely independent ways:  <ins> The corrected_age_value MAY be used as the corrected_initial_age.  In circumstances where very old cache implementations that might not correctly insert </ins>  <ins> are present, corrected_initial_age can be calculated more conservatively as </ins> The current_age of a stored response can then be calculated by adding the time (in seconds) since the stored response was last validated by
Original text:
likely intended for some other (inbound) server. The proper evaluation of conditional requests by a cache depends on <del> the received precondition header fields and their precedence, as defined in precedence.  The </del>  and <del> conditional header fields are not applicable to a cache. </del>  A request containing an

Reviewer comments:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Revised text:
likely intended for some other (inbound) server. The proper evaluation of conditional requests by a cache depends on  <ins> the received precondition header fields and their precedence.  In summary, the </ins> and  <ins> conditional header fields are not applicable to a cache, and takes precedence over . See precedence for a complete specification of precondition precedence. </ins> A request containing an
Original text:
4.3.5. A response to the HEAD method is identical to what an equivalent <del> request made with a GET would have been, except it lacks payload data.  This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the payload data is not desired even if it has changed. </del>  When a cache makes an inbound HEAD request for a target URI and receives a

Reviewer comments:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Revised text:
4.3.5. A response to the HEAD method is identical to what an equivalent  <ins> request made with a GET would have been, without sending the content. This property of HEAD responses can be used to invalidate or update a cached GET response if the more efficient conditional GET request mechanism is not available (due to no validators being present in the stored response) or if transmission of the content is not desired even if it has changed. </ins> When a cache makes an inbound HEAD request for a target URI and receives a
Original text:
The presence of an Age header field implies that the response was not generated or validated by the origin server for this request. However, lack of an Age header field does not imply the origin was <del> contacted, since the response might have been received from an HTTP/1.0 cache that does not implement Age. </del>  5.2.

Reviewer comments:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Revised text:
The presence of an Age header field implies that the response was not generated or validated by the origin server for this request. However, lack of an Age header field does not imply the origin was  <ins> contacted. </ins> 5.2.
Original text:
5.2.1.6. The "no-transform" request directive indicates that the client is <del> asking for intermediaries to avoid transforming the payload, as </del>  defined in message.transformations. 5.2.1.7.

Reviewer comments:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Revised text:
5.2.1.6. The "no-transform" request directive indicates that the client is  <ins> asking for intermediaries to avoid transforming the content, as </ins> defined in message.transformations. 5.2.1.7.
Original text:
The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements <del> for that response's status code.  A cache MUST NOT store a response containing the must-understand directive if the cache does not understand the response status code. </del>  5.2.2.3.

Reviewer comments:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Revised text:
The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements  <ins> for that response's status code. Responses containing "must-understand" SHOULD also contain the "no- store" directive; caches that implement "must-understand" SHOULD ignore the "no-store" directive in responses that contain both directives and a status code that the cache understands and conforms to any related caching requirements. </ins> 5.2.2.3.
Original text:
obey this directive, and communications networks might be vulnerable to eavesdropping.  5.2.2.5. The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the <del> payload, as defined in message.transformations. </del>  5.2.2.6.

Reviewer comments:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Revised text:
obey this directive, and communications networks might be vulnerable to eavesdropping. <ins> Note that the "must-understand" cache directive overrides "no-store" in certain circumstances; see cache-response-directive.must- understand. </ins> 5.2.2.5. The "no-transform" response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the  <ins> content, as defined in message.transformations. </ins> 5.2.2.6.
Original text:
7.1. Various attacks might be amplified by being stored in a shared cache. <del> Such "cache poisoning" attacks use the cache to distribute a malicious payload to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. </del>  One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see

Reviewer comments:
... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.

Revised text:
7.1. Various attacks might be amplified by being stored in a shared cache.  <ins> Such "cache poisoning" attacks use the cache to distribute malicious content to many clients, and are especially effective when an attacker can use implementation flaws, elevated privileges, or other techniques to insert such a response into a cache. </ins> One common attack vector for cache poisoning is to exploit differences in message parsing on proxies and in user agents; see
Original text:
The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements <del> for that response's status code.  A cache MUST NOT store a response containing the must-understand directive if the cache does not understand the response status code. </del>  5.2.2.3.

Reviewer comments:
It occurs to me that if we specify to always be used in conjunction with , and that its semantics are that caches that understand the semantics of the status code can ignore the , all current implementations should already be conferment (if not optimal). Currently, I'm not aware of any cache that implements (because it's new).

Revised text:
The "must-understand" response directive limits caching of the response to a cache that understands and conforms to the requirements  <ins> for that response's status code. Responses containing "must-understand" SHOULD also contain the "no- store" directive; caches that implement "must-understand" SHOULD ignore the "no-store" directive in responses that contain both directives and a status code that the cache understands and conforms to any related caching requirements. </ins> 5.2.2.3.
Original text:
obey this directive, and communications networks might be vulnerable to eavesdropping.  5.2.2.5. The "no-transform" response directive indicates that an intermediary

Reviewer comments:
It occurs to me that if we specify to always be used in conjunction with , and that its semantics are that caches that understand the semantics of the status code can ignore the , all current implementations should already be conferment (if not optimal). Currently, I'm not aware of any cache that implements (because it's new).

Revised text:
obey this directive, and communications networks might be vulnerable to eavesdropping. <ins> Note that the "must-understand" cache directive overrides "no-store" in certain circumstances; see cache-response-directive.must- understand. </ins> 5.2.2.5. The "no-transform" response directive indicates that an intermediary
Original text:
To evaluate a received If-None-Match header field: <del> An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond with either a) the </del>  status code if the request method is GET or HEAD or b) the

Reviewer comments:
They're still requirements, and without the changes, we don't explicitly say how to evaluate the conditionals; elsewhere (e.g., we refer to them as evaluating to either true or false, hence these changes.
I see. Maybe a less intrusive change would be to say: "... The origin server SHOULD NOT perform the requested method if the condition evaluates to false: the selected representation's last modification date is earlier than or equal to the date provided in the field value; instead, the origin server SHOULD generate a 304 (Not Modified) response, including only those metadata that are useful for identifying or updating a previously cached response."
re-specifies precondition processing from . E.g., [...] Do we want to try to fold these into Semantics so that it isn't duplicated? That would require some small adjustments to Semantics AFAICT (e.g., to make it clear what the selected representation is in each case, etc.).
Why not just end each first sentence with ", as defined in Section X.x of Semantics." and remove the rest?
Er, never mind ... having looked at the full section, I think this should stay as is because it is refining the requirements in terms of the cache's stored responses.
I think we can close this. It isn't duplicated: Semantics already refers to this section to define cache handling.
Re-reading the current text, I think I'm finding it most disturbing that semantics 13.1.3 If-Modified-Since doesn't say how to evaluate the condition, whereas caching 4.3.2 does (but just for caches). I think it needs to be removed from caching and made generic. This is necessary because semantics 13.2 refers to evaluation in their algorithms. INM and if-match define how to evaluate, but IMS and IUS don't.
It defines it near the end of the section because of the etag discussion. Anyway, we can improve that.
I proposed a fix for that, but now that is proposed as well, some of the text in caching is clearly duplicative. Will adjust and push another commit or two; please review.
There is a larger problem here -- the section on evaluation was split into two sections (evaluation and precedence) but the conditionals only reference the first. This can be fixed by moving precedence back within evaluation with subsections for the other content in evaluation.
Okay, I have updated the PR to make evaluation one section (with two subsections), fixed a few typos, made the requirements self-descriptive, and updated If-Range to be consistent as well.
(but see comments)

Revised text:
To evaluate a received If-None-Match header field:  <ins> An origin server MUST NOT perform the requested method if a received If-None-Match condition evaluates to false; instead, the origin server MUST respond with either a) the </ins> status code if the request method is GET or HEAD or b) the