jiebi/TextFlow huggingface dataset:
Original text:
message.  However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym.  If a port is not provided, a recipient MAY interpret that as meaning it was <del> received on the default TCP port, if any, for the received-protocol. </del>  A sender MAY generate comments to identify the software of each recipient, analogous to the

Reviewer comments:
Source:
It's completely irrelevant to the recipient what port number was used for an upstream intermediary, which is why it says MAY here.
There are two issues here: 1) The protocol-name doesn't reflect the scheme in use, for HTTPS, it's still 'HTTP'. The practical implication of that is that when HTTPS is used, the port needs to be explicit, even if it's the default for HTTPS. A clarifying note might help here. 2) HTTP/3 uses UDP, not TCP. Omitting 'TCP' from the MAY requirement might help.
This is for Via. HTTPS is not a separate protocol. "https" is a scheme that, among other things, doesn't allow an intermediary to forward HTTP messages until they are beyond the origin secured connection (and hence no longer HTTP/TLS). Whatever the post-TLS origin does to forward its messages via CDN or downstream origins is beyond the scope here.
Yes, we can just remove TCP from that sentence.
That would be acceptable.

Revised text:
message.  However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym.  If a port is not provided, a recipient MAY interpret that as meaning it was  <ins> received on the default port, if any, for the received-protocol. </ins> A sender MAY generate comments to identify the software of each recipient, analogous to the
Original text:
When a cache receives a <del> response and already has one or more stored </del>  <del> responses for the applicable request URI, the cache needs to identify which (if any) are to be updated by the new information provided, and then do so. </del>  <del> The stored response(s) to update are identified by using the first match (if any) of: </del>  For each stored response identified, the cache MUST update its header fields with the header fields provided in the

Reviewer comments:
says: [...] says about : [...] Because we're saying that validation occurs against all responses for a given URI (see ), this has the effect of allowing a response with a header to update all of the responses sent for that URI in that second (provided the requirement about is met) -- which would lead to e.g., response with updating other languages. That probably isn't desirable. The obvious way to fix this is to avoid promoting to a strong validator when it's being used by a cache. However, see -- it's necessary for it to be strong for . It might also be worth refining caching 3.4.3 to differentiate between entity-tag updates and last-modified updates.
In 4.3.5, updating is done like this: Note that it's specified in terms of responses that could have been selected for that request, rather than "stored... responses for the applicable request URI." If we modified 4.3.4 to specify that responses that could have been selected for the request sent are updated (still subject to further filtering down by any validators in the 304 response), I think it should work.

Revised text:
When a cache receives a  <ins> response, it needs to identify stored responses that are suitable for updating with the new information provided, and then do so. </ins>  <ins> The initial set of stored responses to update are those that could have been selected for that request -- i.e., those that meet the requirements in constructing.responses.from.caches, except the last requirement to be fresh, able to be served stale or just validated. </ins>  <ins> Then, that initial set of stored response(s) is further filtered by the first match of: </ins> For each stored response identified, the cache MUST update its header fields with the header fields provided in the
Original text:
4.1. When a cache receives a request that can be satisfied by a stored <del> response that has a </del>  <del> header field (field.vary), it MUST NOT use that response unless all the selecting header fields nominated by the Vary header field match in both the original request (i.e., that associated with the stored response), and the presented request. </del>  The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in

Reviewer comments:
replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...

Revised text:
4.1. When a cache receives a request that can be satisfied by a stored  <ins> response and that stored response contains a </ins>  <ins> header field (field.vary), the cache MUST NOT use that stored response without revalidation unless all the selecting header fields (nominated by that Vary field value) in the present request match those fields in the original request (i.e., the request that caused the cached response to be stored). </ins> The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in
Original text:
absent from a request, it can only match another request if it is also absent there. <del> A </del>  header field value containing a member "*" always fails to match.

Reviewer comments:
replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...

Revised text:
absent from a request, it can only match another request if it is also absent there.  <ins> A stored response with a </ins> header field value containing a member "*" always fails to match.
Original text:
current_age is defined in age.calculations. Clients can send the max-age or min-fresh request directives (cache- <del> request-directive) to constrain or relax freshness calculations for the corresponding response.  However, caches are not required to </del>  honor them. When calculating freshness, to avoid common problems in date parsing:

Reviewer comments:
replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...

Revised text:
current_age is defined in age.calculations. Clients can send the max-age or min-fresh request directives (cache-  <ins> request-directive) to suggest limits on the freshness calculations for the corresponding response.  However, caches are not required to </ins> honor them. When calculating freshness, to avoid common problems in date parsing:
Original text:
A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: <del> Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server. </del>  When there is more than one value present for a given directive (e.g., two

Reviewer comments:
replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...

Revised text:
A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of:  <ins> Note that this calculation is intended to reduce clock skew by using the clock information provided by the origin server whenever possible. </ins> When there is more than one value present for a given directive (e.g., two
Original text:
authority component, an empty Host header field will be sent in this case. <del> To allow for the possibility of a transition to the absolute-form for all requests in some future version of HTTP, a server MUST accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies. </del>  3.2.3.

Reviewer comments:
This is related to the suggestion in but provides the modern reason why all servers work this way.
'This allows servers to be deployed in non-traditional configurations, such as within a custom service mesh or content distribution network, where the proxy/origin distinction is handled upstream.' I don't really buy this; suggest just removing this sentence.

Revised text:
authority component, an empty Host header field will be sent in this case.  <ins> A server MUST accept the absolute-form in requests even though most HTTP/1.1 clients will only send the absolute-form to a proxy. </ins> 3.2.3.
Original text:
pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other <del> response directives at HTTP/1.1 caches.  For example: </del>  will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand

Reviewer comments:
…Control (
See URL
I think we might re-visit this advice, since CC is so widely implemented, but the errata is correct, so yes.

Revised text:
pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other  <ins> request directives at HTTP/1.1 caches.  For example: </ins> will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand
Original text:
host name if the target URI contains a fully qualified domain name. A proxy MUST NOT modify the "absolute-path" and "query" parts of the <del> received target URI when forwarding it to the next inbound server, except as noted above to replace an empty path with "/" or "*". </del>  A proxy MUST NOT transform the content (content) of a message that contains a no-transform cache-control response directive

Reviewer comments:
In semantics 7.7: I found where (in the discussion of normalization in §4.2.3) we say to replace the empty path with "/" for non-OPTIONS requests. I couldn't find anywhere "above" where it was noted to replace an empty path with "*" (presumably, for the OPTIONS requests), though.
This is a reference to text that was moved to HTTP/1.1 because it is version specific. I suggest we replace it with
LGTM

Revised text:
host name if the target URI contains a fully qualified domain name. A proxy MUST NOT modify the "absolute-path" and "query" parts of the  <ins> received target URI when forwarding it to the next inbound server except as required by that forwarding protocol.  For example, a proxy forwarding a request to an origin server via HTTP/1.1 will replace an empty path with "/" (origin-form) or "*" (asterisk-form), depending on the request method. </ins> A proxy MUST NOT transform the content (content) of a message that contains a no-transform cache-control response directive
Original text:
10.1.5. <del> The "Trailer" header field provides a list of field names that the sender anticipates sending as trailer fields within that message. This allows a recipient to prepare for receipt of the indicated metadata before it starts processing the content. For example, a sender might indicate that a signature will be computed as the content is being streamed and provide the final signature as a trailer field.  This allows a recipient to perform the same check on the fly as it receives the content. A sender that intends to generate one or more trailer fields in a message SHOULD generate a header field in the header section of that message to indicate which fields might be present in the trailers. If an intermediary discards the trailer section in transit, the field could provide a hint of what metadata was lost, though there is no guarantee that a sender of Trailer will always follow through by sending the named fields. 10.1.6. </del> The "User-Agent" header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work

Reviewer comments:
This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho

Revised text:
10.1.5.  The "User-Agent" header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work
Original text:
10.2.2. <del> The "Date" header field represents the date and time at which the message was originated, having the same semantics as the Origination Date Field (orig-date) defined in RFC5322.  The field value is an HTTP-date, as defined in http.date. An example is A sender that generates a Date header field SHOULD generate its field value as the best available approximation of the date and time of message generation.  In theory, the date ought to represent the moment just before generating the message content.  In practice, a sender can generate the date value at any time during message origination. An origin server MUST NOT send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instant in Coordinated Universal Time.  An origin server MAY send a Date header field if the response is in the or class of status codes.  An origin server MUST send a Date header field in all other cases. A recipient with a clock that receives a response message without a Date header field MUST record the time it was received and append a corresponding Date header field to the message's header section if it is cached or forwarded downstream. 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. 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 might convey a Date if the server is expected to adjust its interpretation of the user's request based on differences between the user agent and server clocks. 10.2.3. </del> The "Location" header field is used in some responses to refer to a specific resource in relation to the response.  The type of relationship is defined by the combination of request method and

Reviewer comments:
This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho

Revised text:
10.2.2.  The "Location" header field is used in some responses to refer to a specific resource in relation to the response.  The type of relationship is defined by the combination of request method and
Original text:
response is supposed to provide a URI that is specific to the created resource. <del> 10.2.4. </del>  Servers send the "Retry-After" header field to indicate how long the user agent ought to wait before making a follow-up request.  When

Reviewer comments:
This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho

Revised text:
response is supposed to provide a URI that is specific to the created resource.  <ins> 10.2.3. </ins> Servers send the "Retry-After" header field to indicate how long the user agent ought to wait before making a follow-up request.  When
Original text:
In the latter example, the delay is 2 minutes. <del> 10.2.5. </del>  The "Server" header field contains information about the software used by the origin server to handle the request, which is often used

Reviewer comments:
This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho

Revised text:
In the latter example, the delay is 2 minutes.  <ins> 10.2.4. </ins> The "Server" header field contains information about the software used by the origin server to handle the request, which is often used
Original text:
12.5.5. The "Vary" header field in a response describes what parts of a <del> request message, aside from the method and target URI, might influence the origin server's process for selecting and representing </del>  this response. <del> A Vary field value is a list of request field names, known as the selecting header fields, that might have a role in selecting the representation for this response.  Potential selecting header fields are not limited to those defined by this specification. </del>  <del> If the list contains "*", it signals that other aspects of the request might play a role in selecting the response representation, possibly including elements outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate "*" in a Vary field value. </del>  For example, a response that contains

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:
12.5.5. The "Vary" header field in a response describes what parts of a  <ins> request message, aside from the method and target URI, might have influenced the origin server's process for selecting the content of </ins> this response.  <ins> A Vary field value is either the wildcard member "*" or a list of request field names, known as the selecting header fields, that might have had a role in selecting the representation for this response. Potential selecting header fields are not limited to fields defined by this specification. </ins>  <ins> A list containing the member "*" signals that other aspects of the request might have played a role in selecting the response representation, possibly including aspects outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate "*" in a Vary field value. </ins> For example, a response that contains