jiebi/TextFlow huggingface dataset:
Original text:
same Last-Modified time, then at least one of those responses would have a <del> value equal to its Last-Modified time.  The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response.  An implementation MAY use a value larger than 60 seconds, if it is believed that 60 seconds is too short. </del>  7.9.3.

Reviewer comments:
: >A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules: I'm hearing that this 60-second window is problematic for videos, where clients often request a partial video segment within a minute of it being published (thanks to e.g., CMAF). Since those requests use , they require a strong validator. Should we revisit this, given that it is an arbitrarily chosen value by our own admission? I agree that some caution is necessary here, but a one-size-fits-all approach doesn't seem viable.
Discussed on call. Sense is to make this much more based upon the judgement of the implementation, rather than just an arbitrary number.
Suggestion:
NAME NAME - this creates a nested unordered list which comes out really strangely in HTML, please check. Maybe it would be better to have the two statements (that are nested) in a single list entry.

Revised text:
same Last-Modified time, then at least one of those responses would have a  <ins> value equal to its Last-Modified time. </ins> 7.9.3.
Original text:
5.1.  Every HTTP message has a protocol version.  Depending on the version in use, it might be carried in the message explicitly, or it might be inferred by the connection that the message is carried on.  A message

Reviewer comments:
I think this should be something like "Message Framing and Incomplete Messages", and should be after the headers / payload / trailers sections.

Revised text:
5.1. <ins> Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection.  Each major version of HTTP defines its own framing mechanism. HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end each response.  For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early.  For that reason, almost all modern implementations use explicit framing in the form of length- delimited sequences of message data. A message is considered when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete. 5.2. </ins> Every HTTP message has a protocol version.  Depending on the version in use, it might be carried in the message explicitly, or it might be inferred by the connection that the message is carried on.  A message
Original text:
protocol within a protocol element that requires sending a minor version. <del> 5.2. Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection.  Each major version of HTTP defines its own framing mechanism. HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end each response.  For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early.  For that reason, almost all modern implementations use explicit framing in the form of length- delimited sequences of message data. A message is considered when all of the octets indicated by its framing are available.  Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete. </del> 5.3. HTTP messages use key/value pairs to convey data about the message,

Reviewer comments:
I think this should be something like "Message Framing and Incomplete Messages", and should be after the headers / payload / trailers sections.

Revised text:
protocol within a protocol element that requires sending a minor version.  5.3. HTTP messages use key/value pairs to convey data about the message,
Original text:
5.1.  While HTTP's core semantics don't change between protocol versions, the expression of them "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire

Reviewer comments:
This seems out of place, although I understand that versioning is very message-based. I'd suggest putting it in 15. Extending HTTP?
It's not about extending HTTP. The version number literally exists as a field of the message, or at least inherited by the context of the connection, and must be retained by recipients because of version-specific requirements. That's why we need to define both cases as part of the message abstraction.
Fair enough. Can we open the section with a sentence or two that says that it's a field of the message, to give that context? The current text is pretty abstract.

Revised text:
5.1. <ins> Every HTTP message has a protocol version.  Depending on the version in use, it might be carried in the message explicitly, or it might be inferred by the connection that the message is carried on.  A message can change versions as it passes through intermediaries, because the semantics of a HTTP message are independent of its version. </ins> While HTTP's core semantics don't change between protocol versions, the expression of them "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire
Original text:
3.2.  If the request method is GET, the response status code is , and the entire response header section has been received, a cache

Reviewer comments:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Revised text:
3.2. <ins> Caches are required to update a stored response's header fields from another (typically newer) response in several situations; for example, see combining.responses, freshening.responses and head.effects. When doing so, the cache MUST add each header field in the provided response to the stored response, replacing field values that are already present, with the following exceptions: In some cases, caches (especially in user agents) store processed representations of the received response, rather than the response itself, and updating header fields that affect that processing can result in inconsistent behavior and security issues.  Caches in this situation MAY omit these header fields from updating stored representations on an exceptional basis, but SHOULD limit such omission to those fields necessary to assure integrity of the stored representation. For example, a browser might store a response's body after removing content-codings, thereby making its metadata inaccurate.  Updating that stored metadata with a different Content-Encoding header field would be problematic.  Likewise, a browser might store a post-parse tree representation of HTML, rather than the body received in the response; updating the Content-Type header field would not be workable in this case, because any assumptions about the format made in parsing would now be invalid. Furthermore, some fields are automatically processed and removed by the HTTP implementation; for example, the Content-Range header field. Implementations MAY automatically omit such header fields from updates, even when the processing does not actually occur. Note that the Content-* prefix is not a signal that a header field is omitted from update; it is a convention for MIME header fields, not HTTP. 3.3. </ins> If the request method is GET, the response status code is , and the entire response header section has been received, a cache
Original text:
status code. <del> 3.3. </del>  A shared cache MUST NOT use a cached response to a request with an

Reviewer comments:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Revised text:
status code.  <ins> 3.4. </ins> A shared cache MUST NOT use a cached response to a request with an
Original text:
public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage). <del> 3.4. </del>  A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more

Reviewer comments:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Revised text:
public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage).  <ins> 3.5. </ins> A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more
Original text:
requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a <del> cache MUST use the header fields provided in the new response, aside from , to replace all instances of the corresponding header fields in the stored response. </del>  4.

Reviewer comments:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Revised text:
requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a  <ins> cache MUST update the stored response header fields using the header fields provided in the new response, as per update. </ins> 4.
Original text:
The stored response(s) to update are identified by using the first match (if any) of: <del> For each stored response identified for update, the cache MUST use the header fields provided in the response to replace all instances of the corresponding header fields in the stored response, with the following exceptions: In some cases, caches (especially in user agents) store processed representations of the received response, rather than the response itself, and updating header fields that affect that processing can result in inconsistent behavior and security issues.  Caches in this situation MAY omit these header fields from updating stored representations on an exceptional basis, but SHOULD limit such omission to those fields necessary to assure integrity of the stored representation. For example, a browser might store a response's body after removing content-codings, thereby making its metadata inaccurate.  Updating that stored metadata with a different Content-Encoding header field would be problematic.  Likewise, a browser might store a post-parse tree representation of HTML, rather than the body received in the response; updating the Content-Type header field would not be workable in this case, because any assumptions about the format made in parsing would now be invalid. Furthermore, some fields are automatically processed and removed by the HTTP implementation; for example, the Content-Range header field. Implementations MAY automatically omit such header fields from updates, even when the processing does not actually occur. </del>  <del> Note that the Content-* prefix is not a signal that a header field is omitted from update; it is only a convention for naming content- related fields. </del>  4.3.5.

Reviewer comments:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Revised text:
The stored response(s) to update are identified by using the first match (if any) of:  <ins> For each stored response identified, the cache MUST update its header fields with the header fields provided in the </ins>  <ins> response, as per update. </ins> 4.3.5.
Original text:
If a cache updates a stored response with the metadata provided in a HEAD response, the cache MUST use the header fields provided in the <del> HEAD response to replace all instances of the corresponding header fields in the stored response (subject to the exceptions in freshening.responses) and append new header fields to the stored response's header section unless otherwise restricted by the header field. </del>  4.4.

Reviewer comments:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Revised text:
If a cache updates a stored response with the metadata provided in a HEAD response, the cache MUST use the header fields provided in the  <ins> HEAD response to update the stored response (see update). </ins> 4.4.
Original text:
collected.abnf shows the collected grammar with all list operators expanded to standard ABNF notation. <del> The following core rules are included by reference, as defined in RFC5234: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible USASCII character). </del>  Semantics defines the following rules:

Reviewer comments:
"The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character)." Of these, only DIGIT is actually used.

Revised text:
collected.abnf shows the collected grammar with all list operators expanded to standard ABNF notation.  <ins> The following core rule is included by reference, as defined in RFC5234: DIGIT (decimal 0-9). </ins> Semantics defines the following rules:
Original text:
G Grammar <del> ALPHA CR CRLF CTL </del> DIGIT <del> DQUOTE HEXDIG HTAB LF OCTET SP VCHAR </del> H Header Fields

Reviewer comments:
"The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character)." Of these, only DIGIT is actually used.

Revised text:
G Grammar  DIGIT  H Header Fields
Original text:
feeds, traffic cameras, real-time ad selectors, and video-on-demand platforms. <del> 3.6. </del> Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI.  In the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and the origin server (O). <del> The following example illustrates a typical message exchange for a GET request (GET) on the URI "http://www.example.com/hello.txt": Client request: Server response: 3.7. </del>  HTTP enables the use of intermediaries to satisfy requests through a chain of connections.  There are three common forms of HTTP

Reviewer comments:
seems very out of place. I could almost see it as content in 3, as a kind of introduction to the terminology. There are of course other places it could go, but the current location doesn't make much sense.
I moved the ascii art diagram back to the origin server section (where it came from in 7230) since it leads into the other diagrams.

Revised text:
feeds, traffic cameras, real-time ad selectors, and video-on-demand platforms.  Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI.  In the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and the origin server (O).  <ins> 3.6. </ins> HTTP enables the use of intermediaries to satisfy requests through a chain of connections.  There are three common forms of HTTP
Original text:
RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. <del> 3.8. </del>  A "

Reviewer comments:
seems very out of place. I could almost see it as content in 3, as a kind of introduction to the terminology. There are of course other places it could go, but the current location doesn't make much sense.
I moved the ascii art diagram back to the origin server section (where it came from in 7230) since it leads into the other diagrams.

Revised text:
RFC4559) have been known to violate this requirement, resulting in security and interoperability problems.  <ins> 3.7. </ins> A "
Original text:
multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, and so on.  4. Uniform Resource Identifiers (URIs) RFC3986 are used throughout HTTP

Reviewer comments:
seems very out of place. I could almost see it as content in 3, as a kind of introduction to the terminology. There are of course other places it could go, but the current location doesn't make much sense.
I moved the ascii art diagram back to the origin server section (where it came from in 7230) since it leads into the other diagrams.

Revised text:
multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, and so on. <ins> 3.8. The following example illustrates a typical HTTP/1.1 message exchange for a GET request (GET) on the URI "http://www.example.com/ hello.txt": Client request: Server response: </ins> 4. Uniform Resource Identifiers (URIs) RFC3986 are used throughout HTTP
Original text:
response to indicate successful completion of the request. <del> An origin server SHOULD ignore unrecognized header and trailer fields received in a PUT request (i.e., do not save them as part of the resource state). </del> An origin server SHOULD verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or will not be changed by the PUT.  This is

Reviewer comments:
As discussed on call, we need to say that PUT requests can contain response headers, and what that means.

Revised text:
response to indicate successful completion of the request.  An origin server SHOULD verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or will not be changed by the PUT.  This is
Original text:
all implementation details behind the resource interface are intentionally hidden by the server.  An origin server MUST NOT send a validator field (response.validator), such as an

Reviewer comments:
As discussed on call, we need to say that PUT requests can contain response headers, and what that means.

Revised text:
all implementation details behind the resource interface are intentionally hidden by the server. <ins> This extends to how header and trailer fields are stored; while common header fields like will typically be stored and returned upon subsequent GET requests, header and trailer field handling is specific to the resource that received the request.  As a result, an origin server SHOULD ignore unrecognized header and trailer fields received in a PUT request (i.e., do not save them as part of the resource state). </ins> An origin server MUST NOT send a validator field (response.validator), such as an