jiebi/TextFlow huggingface dataset:
Original text:
header table is that the remaining entries are renumbered.  The first entry of the header table is always associated to the index 0. <del> When the modification of the header table is the replacement of an existing entry, the replaced entry is the one indicated in the literal representation before any entry is removed from the header table.  If the entry to be replaced is removed from the header table when performing the size adjustment, the replacement entry is inserted at the beginning of the header table. </del> The addition of a new entry with a size greater than the SETTINGS_HEADER_TABLE_SIZE limit causes all the entries from the header table to be dropped and the new entry not to be added to the <del> header table.  The replacement of an existing entry with a new entry with a size greater than the SETTINGS_HEADER_TABLE_SIZE has the same consequences. </del>  4.

Reviewer comments:
We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .

Revised text:
header table is that the remaining entries are renumbered.  The first entry of the header table is always associated to the index 0.  The addition of a new entry with a size greater than the SETTINGS_HEADER_TABLE_SIZE limit causes all the entries from the header table to be dropped and the new entry not to be added to the  <ins> header table. </ins> 4.
Original text:
A literal header without indexing causes the emission of a header without altering the header table. <del> This representation starts with the '011' 3-bit pattern. </del>  If the header name matches the header name of a (name, value) pair stored in the Header Table, the index of the pair increased by one <del> (index + 1) is represented as an integer with a 5-bit prefix.  Note that if the index is strictly below 31, one byte is used. </del>  If the header name does not match a header name entry, the value 0 is <del> represented on 5 bits followed by the header name </del>  (header.name.representation). Header name representation is followed by the header value

Reviewer comments:
We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .

Revised text:
A literal header without indexing causes the emission of a header without altering the header table.  <ins> This representation starts with the '01' 2-bit pattern. </ins> If the header name matches the header name of a (name, value) pair stored in the Header Table, the index of the pair increased by one  <ins> (index + 1) is represented as an integer with a 6-bit prefix.  Note that if the index is strictly below 63, one byte is used. </ins> If the header name does not match a header name entry, the value 0 is  <ins> represented on 6 bits followed by the header name </ins> (header.name.representation). Header name representation is followed by the header value
Original text:
A literal header with incremental indexing adds a new entry to the header table. <del> This representation starts with the '010' 3-bit pattern. If the header name matches the header name of a (name, value) pair stored in the Header Table, the index of the pair increased by one (index + 1) is represented as an integer with a 5-bit prefix.  Note that if the index is strictly below 31, one byte is used. If the header name does not match a header name entry, the value 0 is represented on 5 bits followed by the header name (header.name.representation). Header name representation is followed by the header value represented as a literal string as described in string.literal.representation. 4.3.3. A literal header with substitution indexing replaces an existing header table entry. </del> This representation starts with the '00' 2-bit pattern. If the header name matches the header name of a (name, value) pair

Reviewer comments:
We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .

Revised text:
A literal header with incremental indexing adds a new entry to the header table.  This representation starts with the '00' 2-bit pattern. If the header name matches the header name of a (name, value) pair
Original text:
represented on 6 bits followed by the header name (header.name.representation). <del> The index of the substituted (name, value) pair is inserted after the header name representation as a 0-bit prefix integer. The index of the substituted pair MUST correspond to a position in the header table containing a non-void entry.  An index for the substituted pair that corresponds to empty position in the header table MUST be treated as an error. This index is followed by the header value represented as a literal string as described in string.literal.representation. </del>  5.

Reviewer comments:
We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .

Revised text:
represented on 6 bits followed by the header name (header.name.representation).  <ins> Header name representation is followed by the header value represented as a literal string as described in string.literal.representation. </ins> 5.
Original text:
The algorithm to represent an integer I is as follows:  4.1.1.1. The value 10 is to be encoded with a 5-bit prefix.

Reviewer comments:
On Sun, Oct 20, 2013 at 05:23:50PM -0700, Roberto Peon wrote: Here's a proposal for that.

Revised text:
The algorithm to represent an integer I is as follows: <ins> This integer representation allows for values of indefinite size.  It is also possible for an encoder to send a large number of zero values, which can waste bytes and could be used to overflow integer values.  Excessively large integer encodings - in value or octet length - MUST be treated as a decoding error.  Different limits can be set for each of the different uses of integers, based on implementation constraints. </ins> 4.1.1.1. The value 10 is to be encoded with a 5-bit prefix.
Original text:
string comparisons is always a function of the total length of the strings, and not a function of the number of matched characters.  Another common security problem is when the remote endpoint successfully causes the local endpoint to exhaust its memory.  This compressor attempts to deal with the most obvious ways that this

Reviewer comments:
On Sun, Oct 20, 2013 at 05:23:50PM -0700, Roberto Peon wrote: Here's a proposal for that.

Revised text:
string comparisons is always a function of the total length of the strings, and not a function of the number of matched characters. <ins> A decoder needs to ensure that larger values or encodings of integers do not permit exploitation.  Decoders MUST limit the size of integers, both in value and encoded length, that it accepts (see integer.representation). </ins> Another common security problem is when the remote endpoint successfully causes the local endpoint to exhaust its memory.  This compressor attempts to deal with the most obvious ways that this
Original text:
The header field corresponding to the referenced entry is emitted. <del> The referenced header table entry is added to the header table. </del>  A _literal representation_ that is _not added_ to the header table entails the following action:

Reviewer comments:
Instructions for Indexed Representation of entry already in header table say to add entry to header table again, don't mention reference set.

Revised text:
The header field corresponding to the referenced entry is emitted.  <ins> The referenced header table entry is added to the reference set. </ins> A _literal representation_ that is _not added_ to the header table entails the following action:
Original text:
triggered the push, plus resource identification information provided by the server.  Request header fields are necessary for HTTP cache control validations (such as the Vary header field) to work.  For <del> this reason, caches MUST inherit request header fields from the associated stream for the push.  This includes the Cookie header field. </del>  Caching resources that are pushed is possible, based on the guidance provided by the origin server in the Cache-Control header field.

Reviewer comments:
We've long since agreed that full request headers are sent in the PUSHPROMISE frame; found a lingering reference to pushed resources "inheriting" headers from the original request. Revised it to reference the request headers in the PUSHPROMISE frame like everywhere else.

Revised text:
triggered the push, plus resource identification information provided by the server.  Request header fields are necessary for HTTP cache control validations (such as the Vary header field) to work.  For  <ins> this reason, caches MUST associate the request header fields from the PUSH_PROMISE frame with the response headers and content delivered on the pushed stream.  This includes the Cookie header field. </ins> Caching resources that are pushed is possible, based on the guidance provided by the origin server in the Cache-Control header field.
Original text:
frame from this client to the remote and receive a response. The value is represented in milliseconds. <del> 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the remote endpoint the maximum number of concurrent streams which it will allow.  By default there is no limit.  For </del>  implementors it is recommended that this value be no smaller <del> than 100. </del>  5 - SETTINGS_CURRENT_CWND allows the sender to inform the remote endpoint of the current TCP CWND value.

Reviewer comments:
This updates the concurrent streams in the XML and updates the HTML too (which picked up some other changes).
"For implementors it is recommended that this value be no smaller than 100" - what is the significance of "for implementers" here? I'm concerned this language is ambiguous enough to cause trouble. E.g., some may read it as pure advice; others might take away that values smaller than 100 can be assumed to be 100. Best way to specify is with MUST/SHOULD/MAY, identifying who it applies to (sender / recipient), and ideally specifying what should happen on both ends of the wire (when generating and receiving).
I agree this is ambiguous. I snuck in a short explanation there. I feel like we should take this back to the working group mailing list. I propose we either commit as is, as my extra explanatory clause is innocuous, and open an issue to resolve the ambiguity. Or I can withdraw this pull request for now, go back to the mailing list, and proceed with the flow control pull request first.
I'm happy to merge now and note an issue; just trying to minimise the number of such edits we cause with each change, as they have a tendency to stack up.

Revised text:
frame from this client to the remote and receive a response. The value is represented in milliseconds.  <ins> 4 - SETTINGS_MAX_CONCURRENT_STREAMS indicates the maximum number of concurrent streams which the sender of the SETTINGS frame is willing to allow the peer to open.  Note that this limit is directional.  By default there is no limit.  For </ins> implementors it is recommended that this value be no smaller  <ins> than 100, so as not to unnecessarily limit parallelism. </ins> 5 - SETTINGS_CURRENT_CWND allows the sender to inform the remote endpoint of the current TCP CWND value.
Original text:
A client that makes a request to an "http" URI without prior knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism (HTTP-p1).  The client makes an HTTP/1.1 request that includes an <del> Upgrade header field identifying HTTP/2.0.  The HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. </del>  Requests that contain an entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that a large

Reviewer comments:
TLS Client Hello's between 256 and 512 bytes need to be rounded up to 512 for compatibility reasons. This incents us to keep Client Hello parameters as small as possible to avoid the rounding - this change shortens the ALPN token of HTTP/2.0 to be simply "h2"
Discussed in Zurich; we will take this and hold back the eventual heat death of the universe a byte at a time.

Revised text:
A client that makes a request to an "http" URI without prior knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism (HTTP-p1).  The client makes an HTTP/1.1 request that includes an  <ins> Upgrade header field identifying HTTP/2.0 with the h2 token.  The HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. </ins> Requests that contain an entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that a large
Original text:
HTTP/2.0 <del> 0x48 0x54 0x54 0x50 0x2f 0x32 0x2e 0x30 ("HTTP/2.0") </del>  This document (RFCXXXX)

Reviewer comments:
TLS Client Hello's between 256 and 512 bytes need to be rounded up to 512 for compatibility reasons. This incents us to keep Client Hello parameters as small as possible to avoid the rounding - this change shortens the ALPN token of HTTP/2.0 to be simply "h2"
Discussed in Zurich; we will take this and hold back the eventual heat death of the universe a byte at a time.

Revised text:
HTTP/2.0  <ins> 0x68 0x32 ("h2") </ins> This document (RFCXXXX)
Original text:
A client can learn that a particular server supports HTTP/2.0 by other means.  A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the ConnectionHeader. <del> This only affects the resolution of "http" URIs; servers supporting HTTP/2.0 are required to support TLSALPN for "https" URIs. </del>  Prior support for HTTP/2.0 is not a strong signal that a given server will support HTTP/2.0 for future connections.  It is possible for

Reviewer comments:
In URL;list=ietf-http-wg, it was proposed that the PRI method be reserved in the HTTP/1.1 method registration document to avoid possible future reservation and ensure that the magic string remains a reliable way of differentiating HTTP/1.1 connections from HTTP/2.0 connections. There was a +1 and some offline discussion along the same vein, no dissent that I heard or saw. However, I don’t see it in URL, presumably because no RFC exists to reference. The appropriate doc is probably HTTP/2.0 rather than breaking the glass on the prepopulated registrations.
There was a question whether "SM" should also be reserved; I personally don't think so, since that line will never be interpreted as a potentially-valid HTTP request line or header. However, I don't think it would break anything if we did.
Break things, no. Squat on prime name-real-estate, a little.

Revised text:
A client can learn that a particular server supports HTTP/2.0 by other means.  A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the ConnectionHeader.  <ins> A server can identify such a connection by the use of the "PRI" method in the connection header.  This only affects the resolution of "http" URIs; servers supporting HTTP/2.0 are required to support TLSALPN for "https" URIs. </ins> Prior support for HTTP/2.0 is not a strong signal that a given server will support HTTP/2.0 for future connections.  It is possible for
Original text:
This document registers the "HTTP2-Settings" header field for use in HTTP.  12.1. This document creates a registration for the identification of

Reviewer comments:
In URL;list=ietf-http-wg, it was proposed that the PRI method be reserved in the HTTP/1.1 method registration document to avoid possible future reservation and ensure that the magic string remains a reliable way of differentiating HTTP/1.1 connections from HTTP/2.0 connections. There was a +1 and some offline discussion along the same vein, no dissent that I heard or saw. However, I don’t see it in URL, presumably because no RFC exists to reference. The appropriate doc is probably HTTP/2.0 rather than breaking the glass on the prepopulated registrations.
There was a question whether "SM" should also be reserved; I personally don't think so, since that line will never be interpreted as a potentially-valid HTTP request line or header. However, I don't think it would break anything if we did.
Break things, no. Squat on prime name-real-estate, a little.

Revised text:
This document registers the "HTTP2-Settings" header field for use in HTTP. <ins> This document registers the "PRI" method for use in HTTP, to avoid collisions with the ConnectionHeader. </ins> 12.1. This document creates a registration for the identification of
Original text:
This header field is only used by an HTTP/2.0 client for Upgrade- based negotiation. 

Reviewer comments:
In URL;list=ietf-http-wg, it was proposed that the PRI method be reserved in the HTTP/1.1 method registration document to avoid possible future reservation and ensure that the magic string remains a reliable way of differentiating HTTP/1.1 connections from HTTP/2.0 connections. There was a +1 and some offline discussion along the same vein, no dissent that I heard or saw. However, I don’t see it in URL, presumably because no RFC exists to reference. The appropriate doc is probably HTTP/2.0 rather than breaking the glass on the prepopulated registrations.
There was a question whether "SM" should also be reserved; I personally don't think so, since that line will never be interpreted as a potentially-valid HTTP request line or header. However, I don't think it would break anything if we did.
Break things, no. Squat on prime name-real-estate, a little.

Revised text:
This header field is only used by an HTTP/2.0 client for Upgrade- based negotiation. <ins> 12.6. This section registers the "PRI" method in the HTTP-p2. PRI No No ConnectionHeader of this document This method is never used by an actual client.  This method will appear to be used when an HTTP/1.1 server or intermediary attempts to parse an HTTP/2.0 connection known-http. </ins>
Original text:
The HTTP pseudo-method CONNECT (HTTP-p2) is used to convert an HTTP/1.1 connection into a tunnel to a remote host.  CONNECT is <del> primarily used with HTTP proxies to established a TLS session with a </del>  server for the purposes of interacting with "https" resources. In HTTP/2.0, the CONNECT method is used to establish a tunnel over a

Reviewer comments:
The sentence in 8.3: "CONNECT is primarily used with HTTP proxies to established a TLS session with a server for the purposes of interacting with https resources." ... does not read. I believe it should be: "CONNECT is primarily used with HTTP proxies to establish a TLS session with a server for the purposes of interacting with https resources." This pull request fixes this incredibly minor issue.

Revised text:
The HTTP pseudo-method CONNECT (HTTP-p2) is used to convert an HTTP/1.1 connection into a tunnel to a remote host.  CONNECT is  <ins> primarily used with HTTP proxies to establish a TLS session with a </ins> server for the purposes of interacting with "https" resources. In HTTP/2.0, the CONNECT method is used to establish a tunnel over a
Original text:
Bit 2 is reserved for future use. <del> Bit 3 being set indicates that the Pad High field is present. This bit MUST NOT be set unless the PAD_LOW flag is also set. </del>  <del> Bit 4 being set indicates that the Pad Low field is present. </del>  DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST

Reviewer comments:
Felt that this order was clearer since the requirement then back-referenced the previous flag instead of forward-referencing it. Feel free to ignore if you disagree.
I considered that option. I think that it's easier if the order of the bits is the same as the order the fields appear. I'll reopen and take this if others point this out though.
Confused by that. In the as-written docs the flags are: [R, R, R, R, PADLOW, PADHIGH, R, ENDSTREAM] but the frame layout is: [PADHIGH (8)], [PAD_LOW(8)] so the order of the bits is opposite the field order.
Let's chalk this up as yet another case of blindness on my part.

Revised text:
Bit 2 is reserved for future use.  <ins> Bit 3 being set indicates that the Pad Low field is present. </ins>  <ins> Bit 4 being set indicates that the Pad High field is present. This bit MUST NOT be set unless the PAD_LOW flag is also set. </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST
Original text:
Abstract <del> This document describes HPACK, a format adapted to efficiently represent HTTP header fields in the context of HTTP/2. </del>  Editorial Note (To be removed by RFC Editor)

Reviewer comments:
Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.

Revised text:
Abstract  <ins> This specification defines HPACK, a compression format for efficiently representing HTTP header fields in the context of HTTP/2. </ins> Editorial Note (To be removed by RFC Editor)
Original text:
The encoding and decoding of header fields relies on some components and concepts: <del> A name-value pair.  Both name and value are sequences of octets. </del>  The header table (see header.table) is a component used to <del> associate stored header fields to index values.  The data stored in this table is in first-in, first-out order. </del>  The static table (see static.table) is a component used to associate static header fields to index values.  This data is

Reviewer comments:
Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.

Revised text:
The encoding and decoding of header fields relies on some components and concepts:  <ins> A name-value pair.  Both the name and value are treated as opaque sequences of octets. </ins> The header table (see header.table) is a component used to  <ins> associate stored header fields to index values. </ins> The static table (see static.table) is a component used to associate static header fields to index values.  This data is