jiebi/TextFlow huggingface dataset:
Original text:
8.3.2. <del> For HTTP/2 responses, a single </del>  <del> pseudo-header field is defined that carries the HTTP status code </del>  field (see HTTP).  This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed.

Reviewer comments:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Revised text:
8.3.2.  <ins> For HTTP/2 responses, a single " </ins>  <ins> " pseudo-header field is defined that carries the HTTP status code </ins> field (see HTTP).  This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed.
Original text:
HTTP cache.  They MAY be made available to the application separately. <del> The server MUST include a value in the </del>  <del> pseudo-header field for which the server is authoritative (see </del>  authority).  A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a StreamErrorHandler of type PROTOCOL_ERROR.

Reviewer comments:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Revised text:
HTTP cache.  They MAY be made available to the application separately.  <ins> The server MUST include a value in the " </ins>  <ins> " pseudo-header field for which the server is authoritative (see </ins> authority).  A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a StreamErrorHandler of type PROTOCOL_ERROR.
Original text:
The header fields in PUSH_PROMISE and any subsequent CONTINUATION frames MUST be a valid and complete set of HttpRequest.  The server <del> MUST include a method in the </del>  <del> pseudo-header field that is safe and cacheable.  If a client receives a PUSH_PROMISE that does not include a complete and valid set of header fields or the </del>  <del> pseudo-header field identifies a method that is not safe, it MUST </del>  respond on the promised stream with a StreamErrorHandler of type PROTOCOL_ERROR.

Reviewer comments:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Revised text:
The header fields in PUSH_PROMISE and any subsequent CONTINUATION frames MUST be a valid and complete set of HttpRequest.  The server  <ins> MUST include a method in the " </ins>  <ins> " pseudo-header field that is safe and cacheable.  If a client receives a PUSH_PROMISE that does not include a complete and valid set of header fields or the " </ins>  <ins> " pseudo-header field identifies a method that is not safe, it MUST </ins> respond on the promised stream with a StreamErrorHandler of type PROTOCOL_ERROR.
Original text:
malformed. A proxy that supports CONNECT establishes a TCP to the host and port <del> identified in the </del>  <del> pseudo-header field.  Once this connection is successfully </del>  established, the proxy sends a HEADERS frame containing a 2xx series status code to the client, as defined in HTTP.

Reviewer comments:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Revised text:
malformed. A proxy that supports CONNECT establishes a TCP to the host and port  <ins> identified in the " </ins>  <ins> " pseudo-header field.  Once this connection is successfully </ins> established, the proxy sends a HEADERS frame containing a 2xx series status code to the client, as defined in HTTP.
Original text:
HttpHeaders does not include specific rules for validation of pseudo- header fields.  If the values of these fields are used, additional <del> validation is necessary.  This is particularly important where </del>  <del> , </del>  <del> , and </del>  <del> are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just </del>  <del> are combined with </del>  <del> to construct a request line (as in HTTP11).  Simple concatenation is not secure unless the input values are fully validated. </del>  An intermediary can reject fields that contain invalid field names or values for other reasons, in particular those that do not conform to

Reviewer comments:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Revised text:
HttpHeaders does not include specific rules for validation of pseudo- header fields.  If the values of these fields are used, additional  <ins> validation is necessary.  This is particularly important where " </ins>  <ins> ", " </ins>  <ins> ", and " </ins>  <ins> " are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just " </ins>  <ins> " are combined with " </ins>  <ins> " to construct a request line (as in HTTP11).  Simple concatenation is not secure unless the input values are fully validated. </ins> An intermediary can reject fields that contain invalid field names or values for other reasons, in particular those that do not conform to
Original text:
For TCP connections without TLS, this depends on the host having resolved to the same IP address. <del> For </del>  <del> resources, connection reuse additionally depends on having a </del>  certificate that is valid for the host in the URI.  The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.  A

Reviewer comments:
Also, use .
and 9.1.1: We quoted "https" where preceded by "resources". Please let us know if this is incorrect. Original: CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with https resources. ... For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. Currently (best viewed in the .html or .pdf output): CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources. ... For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.
Folded into .
: We made quoting consistent around lowercase instances of "http" and "https" when describing URIs or schemed URIs, per quoted instances in , 3.2, and 10.1. Please let us know any objections. Original: http and https schemed URIs http or https schemed URIs http or https URIs Currently: "http" and "https" schemed URIs "http" or "https" schemed URIs "http" or "https" URIs

Revised text:
For TCP connections without TLS, this depends on the host having resolved to the same IP address.  <ins> For " </ins>  <ins> " resources, connection reuse additionally depends on having a </ins> certificate that is valid for the host in the URI.  The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.  A
Original text:
HTTP/2 relies on the HTTP definition of authority for determining whether a server is authoritative in providing a given response (see <del> HTTP).  This relies on local name resolution for the "http" URI scheme and the authenticated server identity for the "https" scheme. </del>  10.2.

Reviewer comments:
Also, use .
and 9.1.1: We quoted "https" where preceded by "resources". Please let us know if this is incorrect. Original: CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with https resources. ... For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. Currently (best viewed in the .html or .pdf output): CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources. ... For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.
Folded into .
: We made quoting consistent around lowercase instances of "http" and "https" when describing URIs or schemed URIs, per quoted instances in , 3.2, and 10.1. Please let us know any objections. Original: http and https schemed URIs http or https schemed URIs http or https URIs Currently: "http" and "https" schemed URIs "http" or "https" schemed URIs "http" or "https" URIs

Revised text:
HTTP/2 relies on the HTTP definition of authority for determining whether a server is authoritative in providing a given response (see  <ins> HTTP).  This relies on local name resolution for the " " URI scheme and the authenticated server identity for the " " scheme. </ins> 10.2.
Original text:
the pushed response as a HttpResponse on a server-initiated stream that uses the promised stream identifier.  The server uses this stream to transmit an HTTP response, using the same sequence of <del> frames as defined in HttpFraming.  This stream becomes StreamStates after the initial HEADERS frame is sent. </del>  Once a client receives a PUSH_PROMISE frame and chooses to accept the pushed response, the client SHOULD NOT issue any requests for the

Reviewer comments:
CLoses .
: Does "the same sequence of frames as defined in " mean "the same sequence of frames as that defined in " or "the same sequence of frames, as defined in "? It appears to us that it means "URL that defined in ", but please advise. Original: The server uses this stream to transmit an HTTP response, using the same sequence of frames as defined in
It means "as that defined in Section 8.1".

Revised text:
the pushed response as a HttpResponse on a server-initiated stream that uses the promised stream identifier.  The server uses this stream to transmit an HTTP response, using the same sequence of  <ins> frames as that defined in HttpFraming.  This stream becomes StreamStates after the initial HEADERS frame is sent. </ins> Once a client receives a PUSH_PROMISE frame and chooses to accept the pushed response, the client SHOULD NOT issue any requests for the
Original text:
In addition to these mechanisms, the PING frame provides a way for a client to easily test a connection.  Connections that remain idle can <del> become broken as some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings. The PING frame allows a client to safely test whether a connection is still active without sending a request. </del>  8.8.

Reviewer comments:
: Does "as" mean "while" or "because" in this sentence? Original: Connections that remain idle can become broken as some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings.
"As" means "because" in this sentence.

Revised text:
In addition to these mechanisms, the PING frame provides a way for a client to easily test a connection.  Connections that remain idle can  <ins> become broken, because some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings.  The PING frame allows a client to safely test whether a connection is still active without sending a request. </ins> 8.8.
Original text:
8.8.3. An HTTP POST request that includes control data and a request header <del> and message content is transmitted as one HEADERS frame, followed by </del>  zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the END_HEADERS flag set and the final DATA

Reviewer comments:
This is awkward, but this is better.
and 8.8.4: Because "control data and a request header and message content" reads a bit oddly, we changed it to "control data and a request header with message content" per "control data and a request header with no message content" in Please let us know if this is incorrect. Original: An HTTP POST request that includes control data and a request header and message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header and message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set: Currently: An HTTP POST request that includes control data and a request header with message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header with message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set:

Revised text:
8.8.3. An HTTP POST request that includes control data and a request header  <ins> with message content is transmitted as one HEADERS frame, followed by </ins> zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the END_HEADERS flag set and the final DATA
Original text:
8.8.4. <del> A response that includes control data and a response header and </del>  message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the END_STREAM flag

Reviewer comments:
This is awkward, but this is better.
and 8.8.4: Because "control data and a request header and message content" reads a bit oddly, we changed it to "control data and a request header with message content" per "control data and a request header with no message content" in Please let us know if this is incorrect. Original: An HTTP POST request that includes control data and a request header and message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header and message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set: Currently: An HTTP POST request that includes control data and a request header with message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header with message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set:

Revised text:
8.8.4.  <ins> A response that includes control data and a response header with </ins> message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the END_STREAM flag
Original text:
The list of prohibited cipher suites includes the cipher suite that TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could have non-intersecting sets of permitted cipher suites.  To avoid this <del> problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS- ECDHE with the P-256 elliptic curve RFC8422. </del>  Note that clients might advertise support of cipher suites that are prohibited in order to allow for connection to servers that do not

Reviewer comments:
: This sentence reads oddly. As it appears that the problem in question causes TLS handshake failures, we updated accordingly. Please let us know if this is incorrect. Original: To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLSECDHERSAWITHAES128GCMSHA256 [TLS-ECDHE] with the P-256 elliptic curve [RFC8422]. Currently: To avoid this problem, which causes TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLSECDHERSAWITHAES128GCMSHA256 [TLS-ECDHE] with the P-256 elliptic curve [RFC8422].

Revised text:
The list of prohibited cipher suites includes the cipher suite that TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could have non-intersecting sets of permitted cipher suites.  To avoid this  <ins> problem, which causes TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P-256 elliptic curve RFC8422. </ins> Note that clients might advertise support of cipher suites that are prohibited in order to allow for connection to servers that do not
Original text:
An intermediary that receives any field that requires removal before forwarding (see HTTP) MUST remove or replace those header fields when forwarding messages.  Additionally, intermediaries should take care <del> when forwarding messages containing Content-Length fields to ensure that the message is malformed.  This ensures that if the message is translated into HTTP/1.1 at any point the framing will be correct. </del>  10.4.

Reviewer comments:
: Should "Content-Length" be enclosed in "" elements in the XML file? We ask because we see three instances of " header field" in the XML for Original:
Probably, yes.

Revised text:
An intermediary that receives any field that requires removal before forwarding (see HTTP) MUST remove or replace those header fields when forwarding messages.  Additionally, intermediaries should take care  <ins> when forwarding messages containing fields to ensure that the message is malformed.  This ensures that if the message is translated into HTTP/1.1 at any point the framing will be correct. </ins> 10.4.
Original text:
10.5. An HTTP/2 connection can demand a greater commitment of resources to <del> operate than an HTTP/1.1 connection.  The use of field section compression and flow control depend on a commitment of resources for storing a greater amount of state.  Settings for these features ensure that memory commitments for these features are strictly bounded. </del>  The number of PUSH_PROMISE frames is not constrained in the same fashion.  A client that accepts server push SHOULD limit the number

Reviewer comments:
: We had trouble parsing this sentence. Does "The use of field section compression and flow control depend" mean "The use of (1) field section compression and (2) flow control depends", or does it mean "Flow control and the use of field section compression depend"? Original: The use of field section compression and flow control depend on a commitment of resources for storing a greater amount of state. Possibly ("Using ... depends"): Using field section compression and flow control depends on a commitment of resources for storing a greater amount of state.
The former is the correct variant, I think.
Suggesting instead:

Revised text:
10.5. An HTTP/2 connection can demand a greater commitment of resources to  <ins> operate than an HTTP/1.1 connection.  Both field section compression and flow control depend on a commitment of a greater amount of state. Settings for these features ensure that memory commitments for these features are strictly bounded. </ins> The number of PUSH_PROMISE frames is not constrained in the same fashion.  A client that accepts server push SHOULD limit the number
Original text:
implementations might be subject to denial of service attack: Most of the features that might be exploited for denial of service -- <del> i.e., SETTINGS changes, small frames, field section compression -- </del>  have legitimate uses.  These features become a burden only when they are used unnecessarily or to excess.

Reviewer comments:
: Please confirm that "i.e.," is correct here (in which case "SETTINGS changes, small frames, field section compression" should be "SETTINGS changes, small frames, and field section compression") instead of "e.g.,". Original: Most of the features that might be exploited for denial of service - i.e., SETTINGS changes, small frames, field section compression - have legitimate uses.
I think that this should probably e.g., not i.e.

Revised text:
implementations might be subject to denial of service attack: Most of the features that might be exploited for denial of service --  <ins> such as SETTINGS changes, small frames, field section compression -- </ins> have legitimate uses.  These features become a burden only when they are used unnecessarily or to excess.
Original text:
Several characteristics of HTTP/2 provide an observer an opportunity to correlate actions of a single client or server over time.  These <del> include the value of settings, the manner in which flow-control </del>  windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings.

Reviewer comments:
Values is correct in the first case, but the second should be "a value" by which it means "any value".
and 10.9: Please confirm that these instances of "value" should not be "values". Original: These include the value of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. Possibly: These include the values of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on secret values is the best defense against any form of timing attack.
These should both be "values".
Values is correct in the first case, but the second should be "a value" by which it means "any value".

Revised text:
Several characteristics of HTTP/2 provide an observer an opportunity to correlate actions of a single client or server over time.  These  <ins> include the values of settings, the manner in which flow-control </ins> windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings.