jiebi/TextFlow huggingface dataset:
Original text:
The response payload, if any, might also describe the communication options in a machine or human-readable representation.  A standard format for such a representation is not defined by this <del> specification, but might be defined by future extensions to HTTP.  A server MUST generate a field with a value of "0" if no payload body is to be sent in the response. </del>  A client MAY send a

Reviewer comments:
: That is incorrect, as the status code could be 204, or the response might come with chunked encoding (even when empty). This is .
What purpose is this requirement serving? It seems to have the effect of prohibiting with a zero length payload. Shouldn't RFC 7230, "3.3.3. Message Body Length" be sufficient for determining payload sizes?
Agreed. The text makes it sound as if OPTIONS is somehow special. Giving advice might be good, but the use of normative keywords makes this confusing. The simplest fix might indeed be to remove the sentence.
LGTM

Revised text:
The response payload, if any, might also describe the communication options in a machine or human-readable representation.  A standard format for such a representation is not defined by this  <ins> specification, but might be defined by future extensions to HTTP. </ins> A client MAY send a
Original text:
explicit expiration time is present in the stored response.  Because of the requirements in response.cacheability, this means that, effectively, heuristics can only be used on responses without <del> explicit freshness whose status codes are defined as cacheable by default (see overview.of.status.codes), and those responses without </del>  explicit freshness that have been marked as explicitly cacheable (e.g., with a "public" response directive).  If the response has a header field (header.last-modified), caches are encouraged to use a

Reviewer comments:
For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.

Revised text:
explicit expiration time is present in the stored response.  Because of the requirements in response.cacheability, this means that, effectively, heuristics can only be used on responses without  <ins> explicit freshness whose status codes are defined as " " (e.g., see overview.of.status.codes), and those responses without </ins> explicit freshness that have been marked as explicitly cacheable (e.g., with a "public" response directive). <ins> Note that in previous specifications heuristically cacheable response status codes were called "cacheable by default." </ins> If the response has a header field (header.last-modified), caches are encouraged to use a
Original text:
, and response.cacheability for details of how public affects responses that would normally not be stored, due to their status <del> codes not being defined as cacheable by default; see </del>  heuristic.freshness.) 5.2.2.6.

Reviewer comments:
For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.

Revised text:
, and response.cacheability for details of how public affects responses that would normally not be stored, due to their status  <ins> codes not being defined as heuristically cacheable; see </ins> heuristic.freshness.) 5.2.2.6.
Original text:
H heuristic expiration time  M max-age (cache directive)

Reviewer comments:
For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.

Revised text:
H heuristic expiration time <ins> heuristically cacheable </ins> M max-age (cache directive)
Original text:
2.1. <del> All HTTP/1.1 messages consist of a start-line followed by a CRLF and a sequence of octets in a format similar to the Internet Message Format RFC5322: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating the end of the header section, and an optional message body. An HTTP message can be either a request from client to server or a response from server to client.  Syntactically, the two types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses), and in the algorithm for determining the length of the message body (message.body). </del>  In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line formats.

Reviewer comments:
As suggested in the issue. Looking at it, more text could be moved up, or the entire section could be moved up (e.g., as a subsection of where this text went), but this seemed reasonable.
-1; this needs to be where CRLF is used, not a different section.
Like that? Wasn't sure what you meant by "moving HTTP version up..."
I meant literally move the section titled "HTTP Version" up above the section titled "Message" and then move "Parsing" to a subsection of "Message". I'll see if I can tweak it.
Would this
... is awfully far from the definition of the message format; IME people read the start of section 3 in isolation and don't see the text below. Maybe move 3.5 up?
Agreed. I have fixed this in 33c709c76bfeafbc2b44b682f1e88f99877e3aca
How about moving the three paras starting with "Although the line terminator..." to 2.1, and moving the out of the definition of and into , to be consistent with ? Then all of the text about is in one place.
See also .
My idea of moving version up to top didn't work out,but moving it down to the third subsection solves both problems, I think.

Revised text:
2.1.  <ins> An HTTP/1.1 message consists of a start-line followed by a CRLF and a sequence of octets in a format similar to the Internet Message Format RFC5322: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating the end of the header section, and an optional message body. A message can be either a request from client to server or a response from server to client.  Syntactically, the two types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses), and in the algorithm for determining the length of the message body (message.body). </ins> In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line formats.
Original text:
Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover from <del> asynchronous close events. When an inbound connection is closed prematurely, a client MAY open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent methods (idempotent.methods). </del>  9.4.2.

Reviewer comments:
As suggested in the issue. Looking at it, more text could be moved up, or the entire section could be moved up (e.g., as a subsection of where this text went), but this seemed reasonable.
-1; this needs to be where CRLF is used, not a different section.
Like that? Wasn't sure what you meant by "moving HTTP version up..."
I meant literally move the section titled "HTTP Version" up above the section titled "Message" and then move "Parsing" to a subsection of "Message". I'll see if I can tweak it.
Would this
... is awfully far from the definition of the message format; IME people read the start of section 3 in isolation and don't see the text below. Maybe move 3.5 up?
Agreed. I have fixed this in 33c709c76bfeafbc2b44b682f1e88f99877e3aca
How about moving the three paras starting with "Although the line terminator..." to 2.1, and moving the out of the definition of and into , to be consistent with ? Then all of the text about is in one place.
See also .
My idea of moving version up to top didn't work out,but moving it down to the third subsection solves both problems, I think.

Revised text:
Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover from  <ins> asynchronous close events.  The conditions under which a client can automatically retry a sequence of outstanding requests are defined in idempotent.methods. </ins> 9.4.2.
Original text:
non-public content, or poison a cache.  See security.considerations for security considerations regarding message routing. <del> 5.4. </del>  The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to

Reviewer comments:
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.

Revised text:
non-public content, or poison a cache.  See security.considerations for security considerations regarding message routing.  <ins> 5.5. </ins> The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to
Original text:
field and to any request message that contains more than one Host header field or a Host header field with an invalid field-value. <del> 5.5. </del>  As described in intermediaries, intermediaries can serve a variety of roles in the processing of HTTP requests and responses.  Some

Reviewer comments:
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.

Revised text:
field and to any request message that contains more than one Host header field or a Host header field with an invalid field-value.  <ins> 5.6. </ins> As described in intermediaries, intermediaries can serve a variety of roles in the processing of HTTP requests and responses.  Some
Original text:
will buffer or delay message forwarding for the sake of network efficiency, security checks, or payload transformations. <del> 5.5.1. </del>  The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server (on

Reviewer comments:
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.

Revised text:
will buffer or delay message forwarding for the sake of network efficiency, security checks, or payload transformations.  <ins> 5.6.1. </ins> The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server (on
Original text:
replaced by pseudonyms.  A sender MUST NOT combine entries that have different received-protocol values. <del> 5.5.2. </del>  Some intermediaries include features for transforming messages and their payloads.  A proxy might, for example, convert between image

Reviewer comments:
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.

Revised text:
replaced by pseudonyms.  A sender MUST NOT combine entries that have different received-protocol values.  <ins> 5.6.2. </ins> Some intermediaries include features for transforming messages and their payloads.  A proxy might, for example, convert between image
Original text:
header field.  The s-maxage directive also implies the semantics of the proxy-revalidate response directive. <del> The must-revalidate directive also has the effect of allowing a stored response to be used to satisfy a request with an Authorization header field; see caching.authenticated.responses. </del>  This directive uses the token form of the argument syntax: e.g., 's-maxage=10' not 's-maxage="10"'.  A sender SHOULD NOT generate the

Reviewer comments:
pasted twice, second should have been s-maxage
The commit d4695a3e422f677d880dc64504c492bf71b6039d for added a paragraph to s-maxage that contains the directive must-revalidate. I think this was supposed to say s-maxage and worded for shared caches?
Sorry, been travelling. This was intentional (although I forgot to update the directive name). implies , which implies . That seems like a lot of indirection in the definition. I agree this wasn't a great way to do it, though. I think the options are: Leave it as is (i.e., two levels of indirection). Leave it as is, but use linking more explicitly so that the indirections can be followed more easily (at least in HTML renderings). Inline the appropriate text from into both and . I think those are ordered according to my preferences, least to most. (I strongly suspect many people don't realise has these semantics, because of it having a name similar to . Making them inline rather than referenced might help)
I agree with the conclusion, but am pretty sure that you meant to say s-maxage in that section defining s-maxage. That's all I changed, so it should be fine unless you wanted to add more text to explain why. I don't think it is necessary to explain more because adding s-maxage implies the server wants shared caches to reuse the response.
I agree with NAME that the additional semantics of are surprising. In particular due to section 4.2.1, comes disguised as the "different value for shared caches". So , and the difference is the handling of error cases like with ? Could you please try to explain why the additional semantics of make sense – that is, why did you not just make it the alternative TTL for shred caches? Thank you!
Ah, okay, so the added paragraph had the right directive before but simply doesn’t make any sense given the context.

Revised text:
header field.  The s-maxage directive also implies the semantics of the proxy-revalidate response directive.  <ins> The s-maxage directive also has the effect of allowing a stored response to be used to satisfy a request with an Authorization header field; see caching.authenticated.responses. </ins> This directive uses the token form of the argument syntax: e.g., 's-maxage=10' not 's-maxage="10"'.  A sender SHOULD NOT generate the
Original text:
5.2.2.6. <del> The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache.  (See caching.authenticated.responses for additional details related to the use of public in response to a request containing </del>  <del> , and response.cacheability for details of how public affects responses that would normally not be stored, due to their status codes not being defined as heuristically cacheable; see heuristic.freshness.) </del>  5.2.2.7.

Reviewer comments:
I think this is the right thing to do; we added too much text here in 7234.
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
I'll trust you on the actual change :-)

Revised text:
5.2.2.6.  <ins> The "public" response directive overrides certain conditions that would otherwise make a cache unable to store the response. Specifically, see caching.authenticated.responses regarding the use of public in response to a request containing </ins>  <ins> , and response.cacheability for how public affects responses that would normally not be stored, due to their status codes not being defined as heuristically cacheable; see heuristic.freshness. </ins> 5.2.2.7.
Original text:
The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared <del> cache.  A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable. </del>  If the private response directive specifies one or more field names, this requirement is limited to the field values associated with the

Reviewer comments:
I think this is the right thing to do; we added too much text here in 7234.
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
I'll trust you on the actual change :-)

Revised text:
The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared  <ins> cache. </ins> If the private response directive specifies one or more field names, this requirement is limited to the field values associated with the
Original text:
trailing whitespace in values is significant will have to use a container syntax such as quoted-string (quoted.strings). <del> Because commas (",") are used as a generic delimiter between field values, they need to be treated with care if they are allowed in the field value.  Typically, components that might contain a comma are protected with double-quotes using the quoted-string ABNF production. </del>  For example, a textual date and a URI (either of which might contain <del> a comma) could be safely carried in field values like these: </del>  Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside double-

Reviewer comments:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Revised text:
trailing whitespace in values is significant will have to use a container syntax such as quoted-string (quoted.strings).  <ins> Because commas (",") are used as a generic delimiter between members of a list-based field value, they need to be treated with care if they are allowed as data within those members.  Typically, list members that might contain a comma are enclosed in a quoted-string. </ins> For example, a textual date and a URI (either of which might contain  <ins> a comma) could be safely carried in list-based field values like these: </ins> Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside double-
Original text:
4.5. A #rule extension to the ABNF rules of RFC5234 is used to improve <del> readability in the definitions of some header field values. </del>  A construct "#" is defined, similar to "*", for defining comma- delimited lists of elements.  The full form is "<n>#<m>element"

Reviewer comments:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Revised text:
4.5. A #rule extension to the ABNF rules of RFC5234 is used to improve  <ins> readability in the definitions of some list-based field values. </ins> A construct "#" is defined, similar to "*", for defining comma- delimited lists of elements.  The full form is "<n>#<m>element"
Original text:
identifying the protocol capabilities of senders along the request/ response chain. <del> Multiple Via field values represent each proxy or gateway that has forwarded the message.  Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients. </del>  A proxy MUST send an appropriate Via header field, as described below, in each message that it forwards.  An HTTP-to-HTTP gateway

Reviewer comments:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Revised text:
identifying the protocol capabilities of senders along the request/ response chain.  <ins> Each member of the Via field value represents a proxy or gateway that has forwarded the message.  Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients. </ins> A proxy MUST send an appropriate Via header field, as described below, in each message that it forwards.  An HTTP-to-HTTP gateway