jiebi/TextFlow huggingface dataset:
Original text:
dynamic table by setting a maximum size of 0, which can subsequently be restored. <del> The size of the dynamic table is the sum of the size of its entries. The size of an entry is the sum of its name's length in octets (as defined in string.literal.representation), its value's length in octets (see string.literal.representation), plus 32. The size of an entry is calculated using the length of the name and value without any Huffman encoding applied. NOTE: The additional 32 octets account for the overhead associated with an entry.  For example, an entry structure using two 64-bit pointers to reference the name and the value of the entry, and two 64-bit integers for counting the number of references to the name and value would have 32 octets of overhead. 4.2. </del>  Whenever the maximum size for the dynamic table is reduced, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to the maximum size. <del> 4.3. </del>  Whenever a new entry is to be added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the

Reviewer comments:
For . Here, I moved the text that covers the calculation of the dynamic header table size up into a new section. Then, I reworded the text to reduce the direct dependency on HTTP/2 and its settings. The emphasis is now on the using protocol setting a maximum, of which the HTTP/2 setting is just an example. Apologies for the diff, I'll try to split the move commit out to make it more readable.
OK, the first commit does the rewording, the second only moves text around.

Revised text:
dynamic table by setting a maximum size of 0, which can subsequently be restored.  <ins> 4.3. </ins> Whenever the maximum size for the dynamic table is reduced, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to the maximum size.  <ins> 4.4. </ins> Whenever a new entry is to be added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the
Original text:
The underlying transport has properties that do not meet minimum security requirements (see TLSUsage).  Unknown or unsupported error codes MUST NOT trigger any special behavior.  These MAY be treated by an implementation as being equivalent to

Reviewer comments:
This is an update of :
There have been a number of discussions about scenarios where we may want the client to fall back to 1.1 (a server forcing gzip, APIs incompatible with HPACK, etc.). HTTP/1.1 defines status code 505 as indicating that the server "refuses to support the major version of HTTP that was used in the request message [and] is unable or unwilling to complete the request using the same major version as the client [...] other than with this error message." However, that doesn't define a programmatic way to tell the user agent what version to retry with, simply a representation to be shown to the user. We should define a way to inform the client what HTTP version to retry with (presumably 1.1).
Discussed in NYC; task force-ish to come up with a proposal either using 505 or a new status code + header to point to the version(s) to bounce to.
Mark to write draft. use 505 extra header what version to down/upgrade to what the scope of applicability is (server vs resource) cache-control applies
Discussed in person, but capturing here: Scope could also be a path prefix, not just a single resource.
Marking this one as non-blocking. We need to discuss adoption of a mechanism for this; and that's not going to happen in the sorts of time frames we're talking about.
Can this be closed -- i.e., do we need to actually reference the new draft in HTTP/2?
Yep.
Reopening (preliminary) based upon feedback from Mike.

Revised text:
The underlying transport has properties that do not meet minimum security requirements (see TLSUsage). <ins> The endpoint requires that HTTP/1.1 be used instead of HTTP/2. </ins> Unknown or unsupported error codes MUST NOT trigger any special behavior.  These MAY be treated by an implementation as being equivalent to
Original text:
This effectively prevents the use of renegotiation in response to a request for a specific protected resource.  A future specification <del> might provide a way to support this use case. </del>  9.2.2.

Reviewer comments:
This is an update of :
There have been a number of discussions about scenarios where we may want the client to fall back to 1.1 (a server forcing gzip, APIs incompatible with HPACK, etc.). HTTP/1.1 defines status code 505 as indicating that the server "refuses to support the major version of HTTP that was used in the request message [and] is unable or unwilling to complete the request using the same major version as the client [...] other than with this error message." However, that doesn't define a programmatic way to tell the user agent what version to retry with, simply a representation to be shown to the user. We should define a way to inform the client what HTTP version to retry with (presumably 1.1).
Discussed in NYC; task force-ish to come up with a proposal either using 505 or a new status code + header to point to the version(s) to bounce to.
Mark to write draft. use 505 extra header what version to down/upgrade to what the scope of applicability is (server vs resource) cache-control applies
Discussed in person, but capturing here: Scope could also be a path prefix, not just a single resource.
Marking this one as non-blocking. We need to discuss adoption of a mechanism for this; and that's not going to happen in the sorts of time frames we're talking about.
Can this be closed -- i.e., do we need to actually reference the new draft in HTTP/2?
Yep.
Reopening (preliminary) based upon feedback from Mike.

Revised text:
This effectively prevents the use of renegotiation in response to a request for a specific protected resource.  A future specification  <ins> might provide a way to support this use case.  Alternatively, a server might use a ConnectionErrorHandler of type to request the client use a protocol which supports renegotiation. </ins> 9.2.2.
Original text:
A header list is an ordered collection of header fields that are encoded jointly, and can contain duplicate header fields.  A <del> complete list of key-value pairs contained in a HTTP/2 header </del>  block is a header list. A header field can be represented in encoded form either as a

Reviewer comments:
I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.

Revised text:
A header list is an ordered collection of header fields that are encoded jointly, and can contain duplicate header fields.  A  <ins> complete list of key-value pairs contained in an HTTP/2 header </ins> block is a header list. A header field can be represented in encoded form either as a
Original text:
HTTP/2 does not use the "Connection" header field to indicate connection-specific header fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT <del> generate a HTTP/2 message containing connection-specific header </del>  fields; any message containing connection-specific header fields MUST be treated as malformed.

Reviewer comments:
I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.

Revised text:
HTTP/2 does not use the "Connection" header field to indicate connection-specific header fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT  <ins> generate an HTTP/2 message containing connection-specific header </ins> fields; any message containing connection-specific header fields MUST be treated as malformed.
Original text:
. Pushed responses that are cacheable (see RFC7234) can be stored by <del> the client, if it implements a HTTP cache.  Pushed responses are </del>  considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive RFC7234 is present) while the stream identified by the promised stream ID is still open.

Reviewer comments:
I think "an" is correct.
An is generally used only before a vowel. As in, "A, E, I, O, and U". An can be used before a "vowel sound" as well. But "h" in "http" is neither in my book. See URL for more info.
In (British?) English, 'h' can be pronounced either as 'aytch' or as 'haytch' so I would say that both 'a' and 'an' HTTP something should be considered fine.
Let's at least be consistent.
If you pronounce 'a' as 'ahh' then "a HTTP" sounds ok. If you pronounce 'a' as 'aye' then it sounds wrong as you have two 'aye' sounds in a row unless you pronounce your 'h' as 'haytch'. American English would generally expect "an" to be used here, I think. Dialects might disagree. RFC 2616 & RFC 7230 use "an".
We had this fight (almost verbatim) for bis; "an" won. As Martin says, let's be consistent.

Revised text:
. Pushed responses that are cacheable (see RFC7234) can be stored by  <ins> the client, if it implements an HTTP cache.  Pushed responses are </ins> considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive RFC7234 is present) while the stream identified by the promised stream ID is still open.
Original text:
The DATA frame defines the following flags: <del> Bit 1 being set indicates that this frame is the last that the </del>  endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates. <del> Bit 4 being set indicates that the Pad Length field and any </del>  padding that it describes is present. DATA frames MUST be associated with a stream.  If a DATA frame is

Reviewer comments:
Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.

Revised text:
The DATA frame defines the following flags:  <ins> Bit 0 being set indicates that this frame is the last that the </ins> endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates.  <ins> Bit 3 being set indicates that the Pad Length field and any </ins> padding that it describes is present. DATA frames MUST be associated with a stream.  If a DATA frame is
Original text:
SETTINGS parameters are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the following flag: <del> Bit 1 being set indicates that this frame acknowledges receipt and </del>  application of the peer's SETTINGS frame.  When this bit is set, the payload of the SETTINGS frame MUST be empty.  Receipt of a SETTINGS frame with the ACK flag set and a length field value

Reviewer comments:
Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.

Revised text:
SETTINGS parameters are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the following flag:  <ins> Bit 0 being set indicates that this frame acknowledges receipt and </ins> application of the peer's SETTINGS frame.  When this bit is set, the payload of the SETTINGS frame MUST be empty.  Receipt of a SETTINGS frame with the ACK flag set and a length field value
Original text:
The PING frame defines the following flags: <del> Bit 1 being set indicates that this PING frame is a PING response. </del>  An endpoint MUST set this flag in PING responses.  An endpoint MUST NOT respond to PING frames containing this flag.

Reviewer comments:
Bits seem to be numbered from 1 to N, which is very confusing since almost every software starts at zero. Also it's common to find macros like : #define BIT(N) (1 << (N)) and here that would introduce mistakes since one constantly has to think about shifting bits before using the macro (eg: BIT(3) to check bit called "4" in the spec, corresponding to value 0x8). Since there are not that many places where this happens, this commit aims at fixing them. Note that the hexadecimal values for each of them were already correct and non-ambiguous.

Revised text:
The PING frame defines the following flags:  <ins> Bit 0 being set indicates that this PING frame is a PING response. </ins> An endpoint MUST set this flag in PING responses.  An endpoint MUST NOT respond to PING frames containing this flag.
Original text:
connections becoming unusable due to limits on the number of messages the underlying cipher suite can encipher. <del> A client MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any </del>  renegotiation MUST occur prior to sending the connection preface.  A server SHOULD request a client certificate if it sees a renegotiation request immediately after establishing a connection.

Reviewer comments:
Two changes here, one editorial and one probably-editorial: The endpoint might send a connection or a stream error of HTTP11_REQUIRED, depending on the scope of the requirement. Note that this was non-normative language, so removing the implication that it would always be a connection error simply makes clearer what was already permitted. The server might know as soon as the connection is established that it will want the cert, but want it protected by the handshake. Either endpoint, not just the client, may choose to renegotiate before sending their preface.

Revised text:
connections becoming unusable due to limits on the number of messages the underlying cipher suite can encipher.  <ins> An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any </ins> renegotiation MUST occur prior to sending the connection preface.  A server SHOULD request a client certificate if it sees a renegotiation request immediately after establishing a connection.
Original text:
This effectively prevents the use of renegotiation in response to a request for a specific protected resource.  A future specification might provide a way to support this use case.  Alternatively, a <del> server might use a ConnectionErrorHandler of type </del>  to request the client use a protocol which supports renegotiation.

Reviewer comments:
Two changes here, one editorial and one probably-editorial: The endpoint might send a connection or a stream error of HTTP11_REQUIRED, depending on the scope of the requirement. Note that this was non-normative language, so removing the implication that it would always be a connection error simply makes clearer what was already permitted. The server might know as soon as the connection is established that it will want the cert, but want it protected by the handshake. Either endpoint, not just the client, may choose to renegotiate before sending their preface.

Revised text:
This effectively prevents the use of renegotiation in response to a request for a specific protected resource.  A future specification might provide a way to support this use case.  Alternatively, a  <ins> server might use an ErrorHandler of type </ins> to request the client use a protocol which supports renegotiation.
Original text:
assigned incorrect or default priority values. Similarly, streams that are in the "idle" state can be assigned <del> priority or become a dependency for other streams.  This allows for the creation of a grouping node in the dependency tree, which enables </del>  more flexible expressions of priority.  Idle streams that are made a <del> dependency are assigned a pri-default. </del>  The retention of priority information for streams that are not counted toward the limit set by

Reviewer comments:
As discussed on the mailing list.
:+1:
Make it so that PRIORITY can be sent on a stream in ANY state. i.e., change so that PRIORITY is permitted in the "idle" state.
Discussed in Honolulu; seems reasonable and no objection. Take to list to confirm.

Revised text:
assigned incorrect or default priority values. Similarly, streams that are in the "idle" state can be assigned  <ins> priority or become a parent of other streams.  This allows for the creation of a grouping node in the dependency tree, which enables </ins> more flexible expressions of priority.  Idle streams that are made a  <ins> parent of another stream are assigned a pri-default. </ins> The retention of priority information for streams that are not counted toward the limit set by
Original text:
(remote)" or "closed" - state, this frame can only affect processing of the current stream and not frame transmission. <del> The PRIORITY frame is the only frame that can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream. </del>  A PRIORITY frame with a length other than 5 octets MUST be treated as a StreamErrorHandler of type

Reviewer comments:
As discussed on the mailing list.
:+1:
Make it so that PRIORITY can be sent on a stream in ANY state. i.e., change so that PRIORITY is permitted in the "idle" state.
Discussed in Honolulu; seems reasonable and no objection. Take to list to confirm.

Revised text:
(remote)" or "closed" - state, this frame can only affect processing of the current stream and not frame transmission.  <ins> The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream. </ins> A PRIORITY frame with a length other than 5 octets MUST be treated as a StreamErrorHandler of type
Original text:
HTTP/2's preference for using a single TCP connection allows correlation of a user's activity on a site.  If connections are reused for different origins, this allows tracking across those <del> origins.  While limited in practicality, this does constitute a new form of tracking. </del>  Because the PING and SETTINGS frames solicit immediate responses, they can be used by an endpoint to measure latency to their peer.

Reviewer comments:
Proposal for
Taking Mark's base, taking Herve's suggestions and removing some text. I think that this is good.
Folks in the Tor community point out that coalescing connections is a genuinely new vector for tracking users in HTTP/2. This should be pointed out in the Privacy Considerations subsection of Security Considerations, along with mitigations. While we're there, more specific text about mitigating HTTP/2-specific fingerprinting would be nice.
NAME I've marked this as Design, but I think we can prepare a proposal pretty easily. You want to take a crack at it, or should I do a pull?
I'm happy to take input. Since I'm basically offline this week, getting a start would help lots.
Marked as editor-ready; please consider list feedback.

Revised text:
HTTP/2's preference for using a single TCP connection allows correlation of a user's activity on a site.  If connections are reused for different origins, this allows tracking across those  <ins> origins. </ins> Because the PING and SETTINGS frames solicit immediate responses, they can be used by an endpoint to measure latency to their peer.
Original text:
that receives a frame that causes their advertised concurrent stream limit to be <del> exceeded MUST treat this as a StreamErrorHandler.  An endpoint that wishes to reduce the value of </del>  to a value that is below the current number of open streams can either close streams that exceed the new value or allow streams to

Reviewer comments:
Rather than just PROTOCOLERROR, allow REFUSEDSTREAM. REFUSED_STREAM is a more lenient error. It allows clients to retry requests. Servers might also set the GOAWAY stream number to a lower value if they upgraded.
"5.1.2 Stream Concurrency" says about SETTINGSMAXCONCURRENT_STREAMS: "Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a HEADERS frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a stream error (Section 5.4.2)" But which stream error code should be used? Almost all other references to stream errors in the spec say "treated as a stream error of type XXX"
Also, if this is a stream error, what happens if the client has a CONTINUATION already in flight right behind the current-streams-violating HEADERS frame? The server would then return a stream error to the HEADERS frame, and then see the CONTINUATION frame that's not associated with an in-progress header block. I suppose a server should maintain enough state to remember that it sent a stream error on that stream ID and simply ignore any following CONTINUATION frames instead of returning a connection error?
The server knows that a continuation frame is coming as it is flagged in the HEADERS frame. Regardless, to ensure against corrupting the compression state, even if it is thrown out, all HEADERS/CONTINUATION data must go through the compression context unless you're closing the connection. This is even true for stream IDs that are not in a valid state (though I'd hope in those cases that the receiver would close the connection after immediately sending an error). , Brad Fitzpatrick EMAIL wrote:
NAME good point. My tests don't cover the case of a CONTINUATION having valuable compression context needed for future valid streams. I will update the test suite I'm building.
Discussed on-list; let's go with .

Revised text:
that receives a frame that causes their advertised concurrent stream limit to be  <ins> exceeded MUST treat this as a StreamErrorHandler of type or .  An endpoint that wishes to reduce the value of </ins> to a value that is below the current number of open streams can either close streams that exceed the new value or allow streams to