jiebi/TextFlow huggingface dataset:
Original text:
. The PRIORITY frame can be sent on a stream in any of the "reserved <del> (remote)", "open", "half closed (local)", or "half closed (remote)" states, though it cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect.  For a stream that is in the "half closed (remote)" state, this frame can only affect processing of the stream and not frame transmission. </del>  6.4.

Reviewer comments:
... as new priority scheme demands and implies, but does not expressly permit. For .

Revised text:
. The PRIORITY frame can be sent on a stream in any of the "reserved  <ins> (remote)", "open", "half closed (local)", "half closed (remote)", or "closed" states, though it cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the current stream.  For a stream that is in the "half closed (remote)" or "closed" - state, this frame can only affect processing of the current stream and not frame transmission. The PRIORITY frame is the only frame that can be sent for a closed stream.  This allows for the reprioritization of a group of dependent streams by altering the priority of the parent stream.  However, a PRIORITY frame sent on a closed stream risks being ignored due to the peer having discarded priority state information for that stream. </ins> 6.4.
Original text:
therefore likely to be more appropriate for use for performance, security or other reasons. <del> Implementations MUST negotiate - and therefore use - ephemeral cipher suites, such as ephemeral Diffie-Hellman (DHE) or the elliptic curve variant (ECDHE) with a minimum size of 2048 bits (DHE) or security level of 128 bits (ECDHE).  Clients MUST accept DHE sizes of up to 4096 bits. Implementations are encouraged not to negotiate TLS cipher suites with known vulnerabilities, such as RC4. An implementation that negotiates a TLS connection that does not meet the requirements in this section, or any policy-based constraints, SHOULD NOT negotiate HTTP/2.  Removing HTTP/2 protocols from consideration could result in the removal of all protocols from the set of protocols offered by the client.  This causes protocol negotiation failure, as described in TLSALPN. Due to implementation limitations, it might not be possible to fail TLS negotiation based on all of these requirements.  An endpoint MUST terminate an HTTP/2 connection that is opened on a TLS session that does not meet these minimum requirements with a ConnectionErrorHandler of type </del>  .

Reviewer comments:
Proposed text for .
This would be consistent with the plan for TLS 1.3.
NAME Firefox hard fails here, which I think is the right decision. I'll confirm with the working group.

Revised text:
therefore likely to be more appropriate for use for performance, security or other reasons.  <ins> The set of TLS cipher suites that are permitted in HTTP/2 is restricted.  HTTP/2 MUST only be used with cipher suites that have ephemeral key exchange, such as the TLS12 or the RFC4492.  Ephemeral key exchange MUST have a minimum size of 2048 bits for DHE or security level of 128 bits for ECDHE.  Clients MUST accept DHE sizes of up to 4096 bits.  HTTP MUST NOT be used with cipher suites that use stream or block ciphers.  Authenticated Encryption with Additional Data (AEAD) modes, such as the RFC5288 are acceptable. Clients MAY advertise support of other cipher suites in order to allow for connection to servers that do not support HTTP/2 to complete without the additional latency imposed by using a separate connection for fallback. An implementation SHOULD NOT negotiate a TLS connection for HTTP/2 without also negotiating a cipher suite that meets these requirements.  Due to implementation limitations, it might not be possible to fail TLS negotiation.  An endpoint MUST immediately terminate an HTTP/2 connection that does not meet these minimum requirements with a ConnectionErrorHandler of type </ins> .
Original text:
. <del> 9.3. Clients MUST support GZIP compression for HTTP response bodies. Regardless of the value of the accept-encoding header field, a server MAY send responses with GZIP encoding.  A compressed response MUST still bear an appropriate content-encoding header field. This effectively changes the implicit value of the Accept-Encoding header field (HTTP-p2) from "identity" to "identity, gzip", however GZIP encoding cannot be suppressed by including ";q=0". Intermediaries that perform translation from HTTP/2 to HTTP/1.1 MUST decompress payloads unless the request includes an Accept-Encoding value that includes "gzip". </del> 10. 10.1.

Reviewer comments:
HTTP/2 requires clients to support the gzip content-coding. The justification for this has always been that it helps avoid intermediaries and other interposed software (e.g., virus filters) that strip Accept-Encoding to avoid the pain of decompressing responses. However, it has been pointed out that doing so means that intermediaries that translate from 1 to 2 are now required to synthesise new entity tags for decompressed responses, breaking semantic transparency and/or losing significant HTTP functionality.
See also .
It also requires to rewrite ETags in request headers (conditional ones), which is an open-ended list. Furthermore, ETags also appear in payloads (WebDAV properties, for instance).
The outcome of this issue also affects
Discussed in NYC; will remove implicit gzip from spec; may create new content-coding required status code or other strategy (non-blocking).

Revised text:
.  10. 10.1.
Original text:
Bit 4 being set indicates that the Pad Length field is present. <del> Bit 6 being set indicates that the data in the frame has been compressed with GZIP compression (GZIP).  Padding is not compressed. </del> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a ConnectionErrorHandler of type . <del> Data frames are optionally compressed using GZIP.  Each frame is individually compressed; the state of the compressor is reset for each frame. An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set unless the setting is enabled, that is, set to 1.  An endpoint that has not enabled DATA frame compression MUST treat the receipt of a DATA frame with the COMPRESSED flag set as a ConnectionErrorHandler of type . </del> DATA frames are subject to flow control and can only be sent when a stream is in the "open" or "half closed (remote)" states.  The entire DATA frame payload is included in flow control, including Pad Low,

Reviewer comments:
Frames can be coalesced or split -- this is antagonistic to end-to-end, per-frame compression. This requires decompression / recompression in proxies that need to coalesce or split frame.
Discussed in NYC; no implementer interest, security concerns about proxying it. We believe it can be addressed as an extension now if someone wants to scratch that itch (and can find someone to interop with); however, fixing this properly means doing it at the HTTP semantic layer (e.g., with a new range type). In the meantime, remove frame compression.

Revised text:
Bit 4 being set indicates that the Pad Length field is present.  DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a ConnectionErrorHandler of type .  DATA frames are subject to flow control and can only be sent when a stream is in the "open" or "half closed (remote)" states.  The entire DATA frame payload is included in flow control, including Pad Low,
Original text:
instead send an ALTSVC frame.  A single ALTSVC frame can be sent for a connection; a new frame is not required for every request.  3.1. When an alternative service is advertised using Alt-Svc, it is

Reviewer comments:
Two minor things here: more strongly recommend the use of the frame type in HTTP/2 over the header field add a frame type number (no need to defer the choice now, this lets people build code based on this)

Revised text:
instead send an ALTSVC frame.  A single ALTSVC frame can be sent for a connection; a new frame is not required for every request. <ins> When using HTTP2, clients SHOULD instead send an ALTSVC frame.  A single ALTSVC frame can be sent for a connection; a new frame is not required for every request. </ins> 3.1. When an alternative service is advertised using Alt-Svc, it is
Original text:
be ignored.  The ALTSVC frame contains the following fields: An unsigned, 32-bit integer indicating the freshness lifetime of

Reviewer comments:
Two minor things here: more strongly recommend the use of the frame type in HTTP/2 over the header field add a frame type number (no need to defer the choice now, this lets people build code based on this)

Revised text:
be ignored. <ins> The ALTSVC frame type is 0xa (decimal 10). </ins> The ALTSVC frame contains the following fields: An unsigned, 32-bit integer indicating the freshness lifetime of
Original text:
7.2.3. A literal header field never indexed representation causes the <del> emission of a header field without altering the header table.  It requires intermediaries to use the same representation for encoding this header field. </del>  A literal header field never indexed representation starts with the '0001' 4-bit pattern.

Reviewer comments:
I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.

Revised text:
7.2.3. A literal header field never indexed representation causes the  <ins> emission of a header field without altering the header table. Intermediaries MUST use the same representation for encoding this header field. </ins> A literal header field never indexed representation starts with the '0001' 4-bit pattern.
Original text:
information leakage to recover any meaningful amount of information (see PETAL). <del> 8.2. </del>  An attacker can try to cause an endpoint to exhaust its memory. HPACK is designed to limit both the peak and state amounts of memory

Reviewer comments:
I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.

Revised text:
information leakage to recover any meaningful amount of information (see PETAL).  <ins> 8.3. </ins> An attacker can try to cause an endpoint to exhaust its memory. HPACK is designed to limit both the peak and state amounts of memory
Original text:
does not force this to occur, application constraints might make this necessary. <del> 8.3. </del>  An implementation of HPACK needs to ensure that large values for integers, long encoding for integers, or long string literals do not

Reviewer comments:
I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.

Revised text:
does not force this to occur, application constraints might make this necessary.  <ins> 8.4. </ins> An implementation of HPACK needs to ensure that large values for integers, long encoding for integers, or long string literals do not
Original text:
connection. Extensions are permitted to use new FrameHeader, SettingValues, <del> ErrorCodes, header fields that start with a colon (:), or any reserved flags or fields in frames.  Of these, registries are established for iana-frames, iana-settings and iana-errors. </del>  Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames <del> that have unknown or unsupported types.  Note that only frames can be flow controlled, extensions cannot be flow controlled. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. </del>  However, extensions can negotiate any use that could change to the semantics of existing protocol components.  For example, an extension

Reviewer comments:
Two small changes here. First, adding unnegotiated semantics to reserved bits in existing frames feels like a REALLY bad idea, since you're almost guaranteed to have collisions, so I'm suggesting we remove that as something that extensions can do unannounced. Second, we permit negotiated changes to existing semantics, so I'm suggesting that instead of saying only DATA will ever be flow controlled, we say that making anything else flow-controlled is a changed semantic that has to be negotiated.
(And as a side-note, section 6.9 implies that there may be frames other than DATA which are flow-controlled defined elsewhere: "Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frame.")

Revised text:
connection. Extensions are permitted to use new FrameHeader, SettingValues,  <ins> ErrorCodes, or header fields that start with a colon (:).  Of these, registries are established for iana-frames, iana-settings and iana- errors. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames  <ins> that have unknown or unsupported types.  This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. </ins> However, extensions can negotiate any use that could change to the semantics of existing protocol components.  For example, an extension
Original text:
frame cannot be used until the peer has given a positive signal that this is acceptable.  In this case, it could also be necessary to <del> coordinate when the revised layout comes into effect. </del>  This document doesn't mandate a specific method for negotiating the use of an extension, but notes that a SettingValues could be used for

Reviewer comments:
Two small changes here. First, adding unnegotiated semantics to reserved bits in existing frames feels like a REALLY bad idea, since you're almost guaranteed to have collisions, so I'm suggesting we remove that as something that extensions can do unannounced. Second, we permit negotiated changes to existing semantics, so I'm suggesting that instead of saying only DATA will ever be flow controlled, we say that making anything else flow-controlled is a changed semantic that has to be negotiated.
(And as a side-note, section 6.9 implies that there may be frames other than DATA which are flow-controlled defined elsewhere: "Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frame.")

Revised text:
frame cannot be used until the peer has given a positive signal that this is acceptable.  In this case, it could also be necessary to  <ins> coordinate when the revised layout comes into effect.  Note that treating any frame other than frames as flow controlled is such a change in semantics, and can only be done through negotiation. </ins> This document doesn't mandate a specific method for negotiating the use of an extension, but notes that a SettingValues could be used for
Original text:
4.3. <del> A header field in HTTP/2 is a name-value pair with one or more associated values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). </del>  Header sets are collections of zero or more header fields.  When transmitted over a connection, a header set is serialized into a

Reviewer comments:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Revised text:
4.3.  <ins> A header field in HTTP/2 is a name with one or more associated values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). </ins> Header sets are collections of zero or more header fields.  When transmitted over a connection, a header set is serialized into a
Original text:
Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream identifiers.  A client that is unable to establish a new stream <del> identifier can establish a new connection for new streams. </del>  5.1.2.

Reviewer comments:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Revised text:
Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream identifiers.  A client that is unable to establish a new stream  <ins> identifier can establish a new connection for new streams.  A server that is unable to establish a new stream identifier may send a frame to require the client to establish a new connection. </ins> 5.1.2.
Original text:
permitted to open.  Streams in any of these three states count toward the limit advertised in the <del> setting. </del>  Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that receives a

Reviewer comments:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Revised text:
permitted to open.  Streams in any of these three states count toward the limit advertised in the  <ins> setting.  Streams in either of the "reserved" states do not count as open. </ins> Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that receives a
Original text:
frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a StreamErrorHandler. <del> Streams in either of the "reserved" states do not count as open. </del> 5.2. Using streams for multiplexing introduces contention over use of the

Reviewer comments:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Revised text:
frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a StreamErrorHandler.  5.2. Using streams for multiplexing introduces contention over use of the
Original text:
prioritization, since the stream could be given a priority that is higher than intended. <del> To avoid these problems, endpoints SHOULD maintain prioritization state for closed streams for a period after streams close. An endpoint SHOULD retain stream prioritization state for a period after streams become closed.  The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values. </del>  This could create a large state burden for an endpoint, so this state MAY be limited.  An endpoint MAY apply a fixed upper limit on the

Reviewer comments:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Revised text:
prioritization, since the stream could be given a priority that is higher than intended.  <ins> To avoid these problems, an endpoint SHOULD retain stream prioritization state for a period after streams become closed.  The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values. </ins> This could create a large state burden for an endpoint, so this state MAY be limited.  An endpoint MAY apply a fixed upper limit on the