jiebi/TextFlow huggingface dataset:
Original text:
A large HeaderBlock can cause an implementation to commit a large amount of state.  Header fields that are critical for routing can appear toward the end of a header block, which prevents streaming of <del> header fields to their ultimate destination.  For this an other </del>  reasons, such as ensuring cache correctness, means that an endpoint might need to buffer the entire header block.  Since there is no hard limit to the size of a header block, some endpoints could be forced

Reviewer comments:
Hey so I have a bunch of typos I found and this is one, "an" –> "and" in the "Limits on Header Block Size" section

Revised text:
A large HeaderBlock can cause an implementation to commit a large amount of state.  Header fields that are critical for routing can appear toward the end of a header block, which prevents streaming of  <ins> header fields to their ultimate destination.  For this and other </ins> reasons, such as ensuring cache correctness, means that an endpoint might need to buffer the entire header block.  Since there is no hard limit to the size of a header block, some endpoints could be forced
Original text:
Promised requests MUST be cacheable (see RFC7231), MUST be safe (see RFC7231) and MUST NOT include a request body.  Clients that receive a <del> promised request that is not cacheable, unsafe or that includes a request body MUST reset the stream with a StreamErrorHandler of type </del>  <del> . </del>  Pushed responses that are cacheable (see RFC7234) can be stored by the client, if it implements an HTTP cache.  Pushed responses are

Reviewer comments:
New safe methods can be defined. Does this mean that the client needs to respond with a stream error for methods not known to be safe? See URL
That would be the only logical conclusion. If the client cannot determine if the method is safe, it must assume that it is not.
Indeed. We just need to fix it.

Revised text:
Promised requests MUST be cacheable (see RFC7231), MUST be safe (see RFC7231) and MUST NOT include a request body.  Clients that receive a  <ins> promised request that is not cacheable, is not known to be safe or that indicates the presence of a request body MUST reset the promised stream with a StreamErrorHandler of type </ins>  <ins> .  Note this could result in the promised stream being reset if the client does not recognize a newly defined method as being safe. </ins> Pushed responses that are cacheable (see RFC7234) can be stored by the client, if it implements an HTTP cache.  Pushed responses are
Original text:
10.6. <del> HTTP/2 enables greater use of compression for both header fields (HeaderBlock) and entity bodies.  Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. </del>  There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., BREACH).  The attacker induces

Reviewer comments:
The latter part is vestigal, from the time when gzip C-E was mandated. Remove it. Here, I'm less concerned.

Revised text:
10.6.  <ins> Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. HTTP/2 enables compression of header fields (HeaderBlock); the following concerns also apply to the use of HTTP compressed content- codings (RFC7231). </ins> There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., BREACH).  The attacker induces
Original text:
unless separate compression dictionaries are used for each source of data.  Compression MUST NOT be used if the source of data cannot be reliably determined.  Generic stream compression, such as that <del> provided by TLS MUST NOT be used with HTTP/2 (TLSUsage). </del>  Further considerations regarding the compression of header fields are described in COMPRESSION.

Reviewer comments:
The latter part is vestigal, from the time when gzip C-E was mandated. Remove it. Here, I'm less concerned.

Revised text:
unless separate compression dictionaries are used for each source of data.  Compression MUST NOT be used if the source of data cannot be reliably determined.  Generic stream compression, such as that  <ins> provided by TLS MUST NOT be used with HTTP/2 (see TLSUsage). </ins> Further considerations regarding the compression of header fields are described in COMPRESSION.
Original text:
streams in a particular order using priority.  Expressing priority is therefore only ever a suggestion. <del> Providing prioritization information is optional, so default values are used if no explicit indicator is provided (pri-default). </del>  5.3.1.

Reviewer comments:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Revised text:
streams in a particular order using priority.  Expressing priority is therefore only ever a suggestion.  <ins> Prioritization information can be omitted from messages.  Defaults are used prior to any explicit values being provided (pri-default). </ins> 5.3.1.
Original text:
5.3.5. <del> Providing priority information is optional.  Streams are assigned a non-exclusive dependency on stream 0x0 by default.  PushResources initially depend on their associated stream.  In both cases, streams are assigned a default weight of 16. </del>  5.4.

Reviewer comments:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Revised text:
5.3.5.  <ins> All streams are initially assigned a non-exclusive dependency on stream 0x0.  PushResources initially depend on their associated stream.  In both cases, streams are assigned a default weight of 16. </ins> 5.4.
Original text:
The DATA frame contains the following fields: An 8-bit field containing the length of the frame padding in units <del> of octets.  This field is optional and is only present if the </del>  PADDED flag is set. Application data.  The amount of data is the remainder of the

Reviewer comments:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Revised text:
The DATA frame contains the following fields: An 8-bit field containing the length of the frame padding in units  <ins> of octets.  This field is conditional and is only present if the </ins> PADDED flag is set. Application data.  The amount of data is the remainder of the
Original text:
The HEADERS frame changes the connection state as described in HeaderBlock. <del> The HEADERS frame includes optional padding.  Padding fields and flags are identical to those defined for DATA. </del>  Prioritization information in a HEADERS frame is logically equivalent to a separate

Reviewer comments:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Revised text:
The HEADERS frame changes the connection state as described in HeaderBlock.  <ins> The HEADERS frame can include padding.  Padding fields and flags are identical to those defined for DATA. </ins> Prioritization information in a HEADERS frame is logically equivalent to a separate
Original text:
. <del> The PUSH_PROMISE frame includes optional padding.  Padding fields and flags are identical to those defined for DATA. </del>  6.7.

Reviewer comments:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Revised text:
.  <ins> The PUSH_PROMISE frame can include padding.  Padding fields and flags are identical to those defined for DATA. </ins> 6.7.
Original text:
responses available in order to fully process the response to the original request. <del> Pushing additional message exchanges in this fashion is optional, and is negotiated between individual endpoints.  The </del>  setting can be set to 0 to indicate that server push is disabled.

Reviewer comments:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Revised text:
responses available in order to fully process the response to the original request.  <ins> A client can request that server push be disabled, though this is negotiated for each hop independently.  The </ins> setting can be set to 0 to indicate that server push is disabled.
Original text:
to correlate actions of a single client or server over time.  This includes the value of settings, the manner in which flow control windows are managed, the way priorities are allocated to streams, <del> timing of reactions to stimulus, and handling of any optional features. </del>  As far as this creates observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined

Reviewer comments:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Revised text:
to correlate actions of a single client or server over time.  This includes the value of settings, the manner in which flow control windows are managed, the way priorities are allocated to streams,  <ins> timing of reactions to stimulus, and handling of any features that are controlled by settings. </ins> As far as this creates observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined
Original text:
PRI <del> No </del>  <del> No </del>  ConnectionHeader of this document

Reviewer comments:
There seems to be some disagreement about this, but I think that Roy is right. It's not critical how it is registered, since it shouldn't appear in a valid request anywhere, but it meets the criteria.
I really don't think it matters, so I'm fine with it either way. Theoretically, there may be some compat value in having it listed as safe/idempotent since an intermediary may be more likely to let such methods pass. But the time slice in which this registry has existed and HTTP/2 hasn't will be miniscule -- I expect any HTTP/2-unaware intermediary won't look at the registry values either.
To the extent that it matters (i.e., very little, as you point out), I think that the intermediary example weakens the case for safe+idempotent. I really don't want HTTP/2 to pass an intermediary without triggering some deliberate recognition; that has been the source of some very serious bugs in the past.

Revised text:
PRI  <ins> Yes </ins>  <ins> Yes </ins> ConnectionHeader of this document
Original text:
of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple <del> concurrent messages on the same connection.  It also introduces </del>  unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the

Reviewer comments:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Revised text:
of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple  <ins> concurrent exchanges on the same connection.  It also introduces </ins> unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the
Original text:
Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are HeaderBlock. This has especially advantageous impact upon request sizes in the <del> common case, allowing many requests to be compressed into one TCP packet. </del>  2.1.

Reviewer comments:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Revised text:
Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are HeaderBlock. This has especially advantageous impact upon request sizes in the  <ins> common case, allowing many requests to be compressed into one packet. </ins> 2.1.
Original text:
An error on the individual HTTP/2 stream. <del> Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" are defined in RFC7230. </del>  3.

Reviewer comments:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Revised text:
An error on the individual HTTP/2 stream.  <ins> Finally, the terms "gateway", "intermediary", "proxy", "tunnel", "message body", and "payload body" are defined in RFC7230. </ins> 3.
Original text:
token.  Such an HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. <del> Requests that contain an entity body MUST be sent in their entirety </del>  before the client can send HTTP/2 frames.  This means that a large <del> request entity can block the use of the connection until it is completely sent. </del>  If concurrency of an initial request with subsequent requests is important, an OPTIONS request can be used to perform the upgrade to

Reviewer comments:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Revised text:
token.  Such an HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field.  <ins> Requests that contain an payload body MUST be sent in their entirety </ins> before the client can send HTTP/2 frames.  This means that a large  <ins> request can block the use of the connection until it is completely sent. </ins> If concurrency of an initial request with subsequent requests is important, an OPTIONS request can be used to perform the upgrade to
Original text:
.  Note that <del> can be sent and received in any stream state.  Frame of unknown types are ignored. </del>  An example of the state transitions for an HTTP request/response exchange can be found in HttpSequence.  An example of the state

Reviewer comments:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Revised text:
.  Note that  <ins> can be sent and received in any stream state.  Frames of unknown types are ignored. </ins> An example of the state transitions for an HTTP request/response exchange can be found in HttpSequence.  An example of the state
Original text:
octets associated with a stream.  One or more DATA frames are used, for instance, to carry HTTP request or response payloads. <del> DATA frames MAY also contain arbitrary padding.  Padding can be added to DATA frames to obscure the size of messages. </del>  The DATA frame contains the following fields:

Reviewer comments:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Revised text:
octets associated with a stream.  One or more DATA frames are used, for instance, to carry HTTP request or response payloads.  <ins> DATA frames MAY also contain padding.  Padding can be added to DATA frames to obscure the size of messages. </ins> The DATA frame contains the following fields:
Original text:
zero or more <del> frames containing the message payload (see RFC7230), and </del>  optionally, one

Reviewer comments:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Revised text:
zero or more  <ins> frames containing the payload body (see RFC7230), and </ins> optionally, one
Original text:
of mandatory header fields, or the inclusion of uppercase header field names. <del> A request or response that includes an entity body can include a </del>  "content-length" header field.  A request or response is also malformed if the value of a "content-length" header field does not equal the sum of the

Reviewer comments:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Revised text:
of mandatory header fields, or the inclusion of uppercase header field names.  <ins> A request or response that includes an payload body can include a </ins> "content-length" header field.  A request or response is also malformed if the value of a "content-length" header field does not equal the sum of the
Original text:
This section shows HTTP/1.1 requests and responses, with illustrations of equivalent HTTP/2 requests and responses. <del> An HTTP GET request includes request header fields and no body and is therefore transmitted as a single </del>  frame, followed by zero or more

Reviewer comments:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Revised text:
This section shows HTTP/1.1 requests and responses, with illustrations of equivalent HTTP/2 requests and responses.  <ins> An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single </ins> frame, followed by zero or more
Original text:
1. In HTTP/1.1 (see RFC7230), header fields are not compressed.  As Web <del> pages have grown to include dozens to hundreds of requests, the </del>  redundant header fields in these requests unnecessarily consume bandwidth, measurably increasing latency.

Reviewer comments:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Revised text:
1. In HTTP/1.1 (see RFC7230), header fields are not compressed.  As Web  <ins> pages have grown to require dozens to hundreds of requests, the </ins> redundant header fields in these requests unnecessarily consume bandwidth, measurably increasing latency.
Original text:
known security attacks, and which has a bounded memory requirement for use in constrained environments.  1.1. The format defined in this specification treats a list of header

Reviewer comments:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Revised text:
known security attacks, and which has a bounded memory requirement for use in constrained environments. <ins> The HPACK format is intentionally simple and inflexible.  Both characteristics reduce the risk of interoperability or security issues based by implementation error.  No extensibility mechanisms are defined; changes to the format are only possible by defining a complete replacement. </ins> 1.1. The format defined in this specification treats a list of header
Original text:
A name-value pair.  Both the name and value are treated as opaque sequences of octets. <del> The dynamic table (see dynamic.table) is a header table used to associate stored header fields to index values.  This table is dynamic and specific to an encoding or decoding context. </del>  <del> The static table (see static.table) is a header table used to associate static header fields to index values.  This table is </del>  ordered, read-only, always accessible, and may be shared amongst all encoding or decoding contexts.

Reviewer comments:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Revised text:
A name-value pair.  Both the name and value are treated as opaque sequences of octets.  <ins> The dynamic table (see dynamic.table) is a table that associates stored header fields with index values.  This table is dynamic and specific to an encoding or decoding context. </ins>  <ins> The static table (see static.table) is a table that statically associates header fields with index values.  This table is </ins> ordered, read-only, always accessible, and may be shared amongst all encoding or decoding contexts.
Original text:
To decompress header blocks, a decoder only needs to maintain a dynamic table (see dynamic.table) as a decoding context.  No other <del> state is needed. </del>  When used for bidirectional communication, such as in HTTP, the encoding and decoding dynamic tables maintained by an endpoint are

Reviewer comments:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Revised text:
To decompress header blocks, a decoder only needs to maintain a dynamic table (see dynamic.table) as a decoding context.  No other  <ins> dynamic state is needed. </ins> When used for bidirectional communication, such as in HTTP, the encoding and decoding dynamic tables maintained by an endpoint are
Original text:
original header list. Once a header field is decoded and added to the reconstructed header <del> list, it cannot be removed from it.  A header field added to the </del>  header list can be safely passed to the application. By passing the resulting header fields to the application, a decoder

Reviewer comments:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Revised text:
original header list. Once a header field is decoded and added to the reconstructed header  <ins> list, the field cannot be removed.  A header field added to the </ins> header list can be safely passed to the application. By passing the resulting header fields to the application, a decoder
Original text:
acknowledgement (see HTTP2). Multiple updates to the maximum table size can occur between the <del> sending of two header blocks.  In the case that the value of this parameter is changed more than once, if any changed value is smaller than the new maximum size, the smallest value for the parameter MUST be sent in an encoding context update.  The altered maximum size is always sent, resulting in at most two encoding context updates.  This ensures that the decoder is able to perform eviction based on the decoder table size (see entry.eviction). </del>  This mechanism can be used to completely clear entries from the dynamic table by setting a maximum size of 0, which can subsequently

Reviewer comments:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Revised text:
acknowledgement (see HTTP2). Multiple updates to the maximum table size can occur between the  <ins> sending of two header blocks.  In the case that this size is changed more than once in this interval, the smallest maximum table size that occurs in that interval MUST be sent in an encoding context update. The final maximum size is always sent, resulting in at most two encoding context updates.  This ensures that the decoder is able to perform eviction based on reductions in decoder table size (see entry.eviction). </ins> This mechanism can be used to completely clear entries from the dynamic table by setting a maximum size of 0, which can subsequently