jiebi/TextFlow huggingface dataset:
Original text:
that requires immediate termination of the connection.  The last stream identifier from the last GOAWAY frame received indicates which streams could have been acted upon.  Endpoints MUST NOT increase the <del> value they send in the last stream identifier, since this could cause their peers to erroneously retry streams if a GOAWAY frame is lost. </del>  A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  This is especially

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:
that requires immediate termination of the connection.  The last stream identifier from the last GOAWAY frame received indicates which streams could have been acted upon.  Endpoints MUST NOT increase the  <ins> value they send in the last stream identifier, since the peers might already have retried unprocessed requests on another connection. </ins> A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  This is especially
Original text:
subject to flow control.  Of the frame types defined in this document, this includes only <del> frame.  Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to </del>  handling the frame.  A receiver MAY respond with a StreamErrorHandler or ConnectionErrorHandler of type

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:
subject to flow control.  Of the frame types defined in this document, this includes only  <ins> frames.  Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to </ins> handling the frame.  A receiver MAY respond with a StreamErrorHandler or ConnectionErrorHandler of type
Original text:
A server that does not wish clients to reuse connections can indicate that it is not authoritative for a request by sending a 421 (Not <del> Authoritative) status code in response to request (see </del>  NotAuthoritative). 9.1.2.

Reviewer comments:
Could have been "a" just as easily, but I felt like a two-character pull request was just overkill.

Revised text:
A server that does not wish clients to reuse connections can indicate that it is not authoritative for a request by sending a 421 (Not  <ins> Authoritative) status code in response to the request (see </ins> NotAuthoritative). 9.1.2.
Original text:
3.3. A client that makes a request to an "https" URI without prior <del> knowledge about support for HTTP/2 uses TLS12 with the TLSALPN. </del>  HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server.

Reviewer comments:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Revised text:
3.3. A client that makes a request to an "https" URI without prior  <ins> knowledge about support for HTTP/2 uses TLS12 with the TLS-ALPN. </ins> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server.
Original text:
such a connection by the use of the "PRI" method in the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST <del> use TLSALPN. </del>  Prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future connections.  It is possible for

Reviewer comments:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Revised text:
such a connection by the use of the "PRI" method in the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST  <ins> use TLS-ALPN. </ins> Prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future connections.  It is possible for
Original text:
use stream or block ciphers.  Authenticated Encryption with Additional Data (AEAD) modes, such as the RFC5288 are acceptable. <del> 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. </del>  An implementation SHOULD NOT negotiate a TLS connection for HTTP/2 without also negotiating a cipher suite that meets these

Reviewer comments:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Revised text:
use stream or block ciphers.  Authenticated Encryption with Additional Data (AEAD) modes, such as the RFC5288 are acceptable.  <ins> The effect of these restrictions is that TLS 1.2 implementations could have non-intersecting sets of available cipher suites, since these prevent the use of the cipher suite that TLS 1.2 makes mandatory.  To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with P256 FIPS186. Clients MAY advertise support of cipher suites that are prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2.  This enables a fallback to protocols without these constraints without the additional latency imposed by using a separate connection for fallback. </ins> An implementation SHOULD NOT negotiate a TLS connection for HTTP/2 without also negotiating a cipher suite that meets these
Original text:
A string for identifying HTTP/2 is entered into the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established <del> in TLSALPN. </del>  This document establishes a registry for frame types, settings, and error codes.  These new registries are entered into a new "Hypertext

Reviewer comments:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Revised text:
A string for identifying HTTP/2 is entered into the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established  <ins> in TLS-ALPN. </ins> This document establishes a registry for frame types, settings, and error codes.  These new registries are entered into a new "Hypertext
Original text:
This document creates two registrations for the identification of HTTP/2 in the "Application Layer Protocol Negotiation (ALPN) Protocol <del> IDs" registry established in TLSALPN. </del>  The "h2" string identifies HTTP/2 when used over TLS:

Reviewer comments:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Revised text:
This document creates two registrations for the identification of HTTP/2 in the "Application Layer Protocol Negotiation (ALPN) Protocol  <ins> IDs" registry established in TLS-ALPN. </ins> The "h2" string identifies HTTP/2 when used over TLS:
Original text:
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 </del>  header block using COMPRESSION.  The serialized header block is then divided into one or more octet sequences, called header block fragments, and transmitted within the payload of HEADERS, PUSH_PROMISE or CONTINUATION frames. <del> HTTP Header Compression does not preserve the relative ordering of header fields.  Header fields with multiple values are encoded into a single header field using a special delimiter (see HeaderOrdering), this preserves the relative order of values for that header field. </del> The COOKIE is treated specially by the HTTP mapping (see CompressCookie). A receiving endpoint reassembles the header block by concatenating its fragments, then decompresses the block to reconstruct the header <del> set. </del>  A complete header block consists of either:

Reviewer comments:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Revised text:
values.  They are used within HTTP request and response messages as well as server push operations (see PushResources).  <ins> Header lists are collections of zero or more header fields.  When transmitted over a connection, a header list is serialized into a </ins> header block using COMPRESSION.  The serialized header block is then divided into one or more octet sequences, called header block fragments, and transmitted within the payload of HEADERS, PUSH_PROMISE or CONTINUATION frames.  The COOKIE is treated specially by the HTTP mapping (see CompressCookie). A receiving endpoint reassembles the header block by concatenating its fragments, then decompresses the block to reconstruct the header  <ins> list. </ins> A complete header block consists of either:
Original text:
Field Registry maintained at <https://www.iana.org/assignments/ message-headers>.  While HTTP/1.x used the message start-line (see RFC7230) to convey the target URI and method of the request, and the status code for the response, HTTP/2 uses special pseudo-header fields beginning with ':'

Reviewer comments:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Revised text:
Field Registry maintained at <https://www.iana.org/assignments/ message-headers>. <ins> 8.1.2.1. </ins> While HTTP/1.x used the message start-line (see RFC7230) to convey the target URI and method of the request, and the status code for the response, HTTP/2 uses special pseudo-header fields beginning with ':'
Original text:
encoding in HTTP/2.  A request or response containing uppercase header field names MUST be treated as malformed.  HTTP/2 does not use the Connection header field to indicate "hop-by- hop" header fields; in this protocol, connection-specific metadata is conveyed by other means.  As such, a HTTP/2 message containing

Reviewer comments:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Revised text:
encoding in HTTP/2.  A request or response containing uppercase header field names MUST be treated as malformed. <ins> All pseudo-header fields MUST appear in the header block before regular header fields.  Any request or response that contains any pseudo-header field that appears in a header block after a regular header field MUST treated as malformed. 8.1.2.2. </ins> HTTP/2 does not use the Connection header field to indicate "hop-by- hop" header fields; in this protocol, connection-specific metadata is conveyed by other means.  As such, a HTTP/2 message containing
Original text:
The handshake methods described in starting are believed sufficient to negotiate the use of alternative protocols. <del> 8.1.2.1. </del>  HTTP/2 defines a number of pseudo header fields starting with a colon ':' character that carry information about the request target:

Reviewer comments:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Revised text:
The handshake methods described in starting are believed sufficient to negotiate the use of alternative protocols.  <ins> 8.1.2.3. </ins> HTTP/2 defines a number of pseudo header fields starting with a colon ':' character that carry information about the request target:
Original text:
HTTP/2 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line. <del> 8.1.2.2. </del>  A single ":status" header field is defined that carries the HTTP status code field (see RFC7231).  This header field MUST be included

Reviewer comments:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Revised text:
HTTP/2 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line.  <ins> 8.1.2.4. </ins> A single ":status" header field is defined that carries the HTTP status code field (see RFC7231).  This header field MUST be included
Original text:
HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line. <del> 8.1.2.3. COMPRESSION does not preserve the order of header fields, because the relative order of header fields with different names is not important.  However, the same header field can be repeated to form a list (see RFC7230), where the relative order of header field values is significant.  This repetition can occur either as a single header field with a comma-separated list of values, or as several header fields with a single value, or any combination thereof.  Therefore, in the latter case, ordering needs to be preserved before compression takes place. To preserve the order of multiple occurrences of a header field with the same name, its ordered values are concatenated into a single value using a zero-valued octet (0x0) to delimit them. After decompression, header fields that have values containing zero octets (0x0) MUST be split into multiple header fields before being processed. For example, the following HTTP/1.x header block: contains three Cache-Control directives; two directives in the first Cache-Control header field, and the third directive in the second Cache-Control field.  Before compression, they would need to be converted to a form similar to this (with 0x0 represented as '\0'): Note here that the ordering between Content-Type and Cache-Control is not preserved, but the relative ordering of the Cache-Control directives - as well as the fact that the first two were comma- separated, while the last was on a different line - is. Header fields containing multiple values MUST be concatenated into a single value unless the ordering of that header field is known to be not significant. The special case of "set-cookie" - which does not form a comma- separated list, but can have multiple values - does not depend on ordering.  The "set-cookie" header field MAY be encoded as multiple header field values, or as a single concatenated value. 8.1.2.4. </del>  The COOKIE can carry a significant amount of redundant data.

Reviewer comments:
Now that we have decided to remove the reference set, the hacks we added to address header field ordering are no longer entirely necessary. This change does the following: remove the requirement to concatenate with '\0' require pseudo-header fields to all appear before regular header fields change 'header set' to 'header list'
This has implications beyond ordering w.r.t. compression efficiency, especially now that the number of items incurs a cost per item. , Martin Thomson EMAIL wrote:
nice, more red than green :)
Included into HPACK. Encoder and decoder SHOULD preserve ordering. :headers MUST appear before normal headers (in both encoded and decoded lists).

Revised text:
HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line.  <ins> 8.1.2.5. </ins> The COOKIE can carry a significant amount of redundant data.