jiebi/TextFlow huggingface dataset:
Original text:
representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation.  A client MUST NOT generate an If-Range header field in a request that does not contain a

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:
representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation. <ins> A valid can be distinguished from a valid by examining the first three characters for a DQUOTE. </ins> A client MUST NOT generate an If-Range header field in a request that does not contain a
Original text:
13.2.  Except when excluded below, a recipient cache or origin server MUST evaluate received request preconditions after it has successfully performed its normal request checks and just before it would process

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:
13.2. <ins> 13.2.1. </ins> Except when excluded below, a recipient cache or origin server MUST evaluate received request preconditions after it has successfully performed its normal request checks and just before it would process
Original text:
response. <del> 13.3. </del>  When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes

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:
response.  <ins> 13.2.2. </ins> When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes
Original text:
corresponding Date header field to the message's header section if it is cached or forwarded downstream.  A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server.  For example, custom applications of HTTP

Reviewer comments:
Those changes are editorial.
specifies what to do when it isn't present (use the received time), but not what to do when it doesn't parse. The intuitive thing to do is align, and say that the received time should be used in this situation as well -- but probably not require implementations to replace it if forwarded. I might write some tests...
Okay, I am still waiting on those new glasses. Too much Age. It's fine with me if we interpret an invalid Date as the received time, but that assumes we know the received time when we parse the Date. I think as long as the scope is specific to Caching, we should specify that a cache always record the time received (regardless of Date) and use the received time if the Date field value is invalid.
is used in a number of places in caching, so that modification will be pretty invasive. Why do you think it needs to be restrained to just caching? I suppose it could be specified in semantics as something like 'If the Date field value does not parse, it MAY be replaced with the time the message was received. Caches SHOULD consider the message receipt time as the Date value when it cannot be parsed.'
The "it" in that last sentence has an unclear subject (is it the date, the arrival time, or the cache?), and "consider" -> "use".
The only reason I said it is okay for caching is because we already depend on the cache having a clock and storing time received. It seems reasonable, regardless of role, if the recipient has a clock. But I wasn't suggesting a new requirement.

Revised text:
corresponding Date header field to the message's header section if it is cached or forwarded downstream. <ins> A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received. </ins> A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server.  For example, custom applications of HTTP
Original text:
the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email.  Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable <del> whitelist of safe request targets. </del>  A server MUST NOT send any

Reviewer comments:
Without getting into the current politics and history of the term, there are two instances of this term in SEMANTICS that don't appear to contribute substantial value versus using a less loaded choice. : Here, "list" seems sufficient. Perhaps "sites that have been explicitly permitted"?
Good catch. I thought I already checked for those when I replaced man-in-the-middle.
For a direct replacement both safelist and allowlist have seen some uptake.

Revised text:
the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email.  Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable  <ins> list of safe request targets. </ins> A server MUST NOT send any
Original text:
might be strongly correlated to membership in a particular ethnic group.  An approach that limits such loss of privacy would be for a user agent to omit the sending of Accept-Language except for sites <del> that have been whitelisted, perhaps via interaction after detecting a </del>  header field that indicates language negotiation might be useful.

Reviewer comments:
Without getting into the current politics and history of the term, there are two instances of this term in SEMANTICS that don't appear to contribute substantial value versus using a less loaded choice. : Here, "list" seems sufficient. Perhaps "sites that have been explicitly permitted"?
Good catch. I thought I already checked for those when I replaced man-in-the-middle.
For a direct replacement both safelist and allowlist have seen some uptake.

Revised text:
might be strongly correlated to membership in a particular ethnic group.  An approach that limits such loss of privacy would be for a user agent to omit the sending of Accept-Language except for sites  <ins> that have been explicitly permitted, perhaps via interaction after detecting a </ins> header field that indicates language negotiation might be useful.
Original text:
inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with <del> third-party HTTP servers ought to conform to user agent requirements </del>  on the gateway's inbound connection. A

Reviewer comments:
This isn't a place for equivocation. This could have been MUST except that that isn't good to use here. I considered just "conforms to" as well. That would also work, but that is incompatible with "wishes to" and I was less confident in removing that. I could do "conforms to" with "gateway that interoperates with inbound HTTP servers", but that's a bigger change.

Revised text:
inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with  <ins> third-party HTTP servers needs to conform to user agent requirements </ins> on the gateway's inbound connection. A
Original text:
specifically means that the server has been authenticated as acting on behalf of the identified authority and all HTTP communication with <del> that server has been protected for confidentiality and integrity through the use of strong encryption. </del>  The origin server for an "https" URI is identified by the

Reviewer comments:
In the definition of the https scheme, the phrase "strong encryption" is used. This implies some sort of judgment. I think that the key is that both client and server need to agree on the adequacy of the protections. Noting that this might be contextual is somewhat obvious at that point, but I thought it might be worth pointing out that what is generally acceptable might change over time.

Revised text:
specifically means that the server has been authenticated as acting on behalf of the identified authority and all HTTP communication with  <ins> that server has confidentiality and integrity protection that is acceptable to both client and server. </ins> The origin server for an "https" URI is identified by the
Original text:
A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts <del> secured responses to those requests. </del>  Resources made available via the "https" scheme have no shared identity with the "http" scheme.  They are distinct origins with

Reviewer comments:
In the definition of the https scheme, the phrase "strong encryption" is used. This implies some sort of judgment. I think that the key is that both client and server need to agree on the adequacy of the protections. Noting that this might be contextual is somewhat obvious at that point, but I thought it might be worth pointing out that what is generally acceptable might change over time.

Revised text:
A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts  <ins> secured responses to those requests.  Note that the definition of what cryptographic mechanisms are acceptable to client and server are usually negotiated and can change over time. </ins> Resources made available via the "https" scheme have no shared identity with the "http" scheme.  They are distinct origins with
Original text:
how trailer field values can be safely merged. The presence of the keyword "trailers" in the TE header field <del> (field.te) indicates that the client is willing to accept trailer fields, on behalf of itself and any downstream clients.  For requests from an intermediary, this implies that all downstream clients are willing to accept trailer fields in the forwarded response.  Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the trailer section(s) will not be dropped by any of the clients. </del>  Because of the potential for trailer fields to be discarded in transit, a server SHOULD NOT generate trailer fields that it believes

Reviewer comments:
I know that this is pretty obvious and implied, but maybe it's worth saying.
maybe just s/TE header field/TE request header field/?

Revised text:
how trailer field values can be safely merged. The presence of the keyword "trailers" in the TE header field  <ins> (field.te) of a request indicates that the client is willing to accept trailer fields, on behalf of itself and any downstream clients.  For requests from an intermediary, this implies that all downstream clients are willing to accept trailer fields in the forwarded response.  Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the trailer section(s) will not be dropped by any of the clients. </ins> Because of the potential for trailer fields to be discarded in transit, a server SHOULD NOT generate trailer fields that it believes
Original text:
9.3.2. The HEAD method is identical to GET except that the server MUST NOT <del> send content in the response and the response always terminates at the end of the header section.  HEAD is used to obtain metadata about </del>  the without transferring its representation data, often for the sake of

Reviewer comments:
Though I think that this text is correct, an HTTP/3 response only ends when the stream is closed, not at the end of the header section. I think that it's not necessary to say this bit anyway.
The related parts were done in so this bit can be applied now as editorial.

Revised text:
9.3.2. The HEAD method is identical to GET except that the server MUST NOT  <ins> send content in the response.  HEAD is used to obtain metadata about </ins> the without transferring its representation data, often for the sake of
Original text:
mapping its semantics into the protocol's wire format. CONNECT is intended only for use in requests to a proxy.  An origin <del> server that receives a CONNECT request for itself MAY respond with a status code to indicate that a connection is established.  However, most origin servers do not implement CONNECT. </del>  The recipient proxy can establish a tunnel either by directly connecting to the request target or, if configured to use another

Reviewer comments:
The original text here sort of implied that it was enough for an origin server to just send 2xx. That assumed that the request was for the origin server itself and elided a bunch of detail. This is shorter and clearer, I think.
I didn't intend anything here other than a clarification of what was written. I'm mostly guessing what was intended as I don't know what the original text truly intended to say. (I think that it was always possible to use CONNECT with a target of the origin server to do URL But I didn't want to highlight that here; it's a little bit of an odd thing to decide to do and so I wouldn't want to encourage it.)

Revised text:
mapping its semantics into the protocol's wire format. CONNECT is intended only for use in requests to a proxy.  An origin  <ins> server MAY accept a CONNECT request, but most origin servers do not implement CONNECT. </ins> The recipient proxy can establish a tunnel either by directly connecting to the request target or, if configured to use another
Original text:
5.6.2.  Many HTTP field values are defined using common syntax components, separated by whitespace or specific delimiting characters. Delimiters are chosen from the set of US-ASCII visual characters not

Reviewer comments:
The first paragraph of the section 5.6.2 on Tokens, which describes delimiters, is misplaced. It should either be the last paragraph in that section or the first paragraph in the parent (Common Rules).
Moving it up would be a bit strange because to the reference to tokens. Moving to the end of the section seems good though.

Revised text:
5.6.2. <ins> Tokens are short textual identifiers that do not include whitespace or delimiters. </ins> Many HTTP field values are defined using common syntax components, separated by whitespace or specific delimiting characters. Delimiters are chosen from the set of US-ASCII visual characters not
Original text:
(DQUOTE and "(),/:;<=>?@[\]{}"). <del> Tokens are short textual identifiers that do not include whitespace or delimiters. </del> 5.6.3. This specification uses three rules to denote the use of linear

Reviewer comments:
The first paragraph of the section 5.6.2 on Tokens, which describes delimiters, is misplaced. It should either be the last paragraph in that section or the first paragraph in the parent (Common Rules).
Moving it up would be a bit strange because to the reference to tokens. Moving to the end of the section seems good though.

Revised text:
(DQUOTE and "(),/:;<=>?@[\]{}").  5.6.3. This specification uses three rules to denote the use of linear
Original text:
charset ISO-8859-1, supporting other charsets only through use of RFC2047 encoding.  In practice, most HTTP field values use only a subset of the US-ASCII charset USASCII.  Newly defined fields SHOULD <del> limit their values to US-ASCII octets.  A recipient SHOULD treat other octets in field content (obs-text) as opaque data. </del>  Field values containing control (

Reviewer comments:
In : This is probably overly broad considering that the ABNF says (I question the wisdom of including HTAB, but now is not the time to worry about that). Could this be changed to "printable or visible US-ASCII octets, plus SP and HTAB"? (Incidentally, why doesn't the rule use the ABNF rule?)

Revised text:
charset ISO-8859-1, supporting other charsets only through use of RFC2047 encoding.  In practice, most HTTP field values use only a subset of the US-ASCII charset USASCII.  Newly defined fields SHOULD  <ins> limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB. A recipient SHOULD treat other octets in field content (obs-text) as opaque data. </ins> Field values containing control (