jiebi/TextFlow huggingface dataset:
Original text:
4.4. <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 dynamic table is less than or equal to (maximum size - new entry size), or until the table is empty. </del>  If the representation of the added entry references the name of an entry in the dynamic table, the referenced name is cached prior to

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

Revised text:
4.4.  <ins> Before a new entry is added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (maximum size - new entry size), or until the table is empty. </ins> If the representation of the added entry references the name of an entry in the dynamic table, the referenced name is cached prior to
Original text:
frame has the END_HEADERS flag set. Header compression is stateful.  One compression context and one <del> decompression context is used for the entire connection.  Each header block is processed as a discrete unit.  Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The last frame in a sequence of </del>  or

Reviewer comments:
Proposal to replace . I think that this is a little clearer this way. Also, it's strange that this was not added earlier, but then sometimes the most obvious things get missed. cc NAME
So I'm not seeing how the new sentence is any different than this one two paragraphs below: A receiver MUST terminate the connection with a connection error of type COMPRESSIONERROR if it does not decompress a header block. My chief concern (merely editorial) is that HPACK consistently uses the phrase "decoding error" whereas here we are using the phrase "decompress." I think it good to make clear that any and all decoding errors MUST result in connection errors of type COMPRESSIONERROR. Picky, I know. ;-)
I think that Martin's proposal tries to specifically address your concern. The sentence two paragraphs below address the case of an endpoint deciding for whatever reason not to decompress a header block: this also has to result in a COMPRESSION_ERROR. So I think that both are useful.
Ahhh - thanks NAME Makes perfect sense and I agree.

Revised text:
frame has the END_HEADERS flag set. Header compression is stateful.  One compression context and one  <ins> decompression context is used for the entire connection.  A decoding error in a header block MUST be treated as a ConnectionErrorHandler of type . Each header block is processed as a discrete unit.  Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The last frame in a sequence of </ins> or
Original text:
frame. <del> The HTTP/1.1 request that is sent prior to upgrade is assigned stream identifier 1 and is assigned pri-default.  Stream 1 is implicitly half closed from the client toward the server, since the request is completed as an HTTP/1.1 request.  After commencing the HTTP/2 connection, stream 1 is used for the response. </del>  3.2.1.

Reviewer comments:
Fixes for those things that were obviously busted. Which (I hope) addresses the comments, with one exception (Richard's discuss contained suggested edits that should clear that one up).

Revised text:
frame.  <ins> The HTTP/1.1 request that is sent prior to upgrade is assigned a stream identifier of 1 (see StreamIdentifiers) with pri-default. Stream 1 is implicitly "half closed" from the client toward the server (see StreamStates), since the request is completed as an HTTP/1.1 request.  After commencing the HTTP/2 connection, stream 1 is used for the response. </ins> 3.2.1.
Original text:
Either the client or server of the connection. <del> The smallest unit of communication, each containing a frame header. </del>  A complete sequence of frames.

Reviewer comments:
Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,

Revised text:
Either the client or server of the connection.  <ins> The smallest unit of communication within an HTTP/2.0 session, consisting of a header and a variable-length sequence of bytes structured according to the frame type. </ins> A complete sequence of frames.
Original text:
An error on the HTTP/2.0 session. <del> A bi-directional flow of bytes across a virtual channel within the HTTP/2.0 session. </del>  An error on the individual HTTP/2.0 stream. 2. <del> Just as HTTP/1.1 does, HTTP/2.0 uses the "http:" and "https:" URI schemes.  An HTTP/2.0-capable client is therefore required to discover whether the upstream server (including intermediaries) supports HTTP/2.0. </del>  <del> Different discovery mechanisms are defined for "http:" and "https:" URIs.  Discovery for "http:" URIs is described in discover-http; discovery for "https:" URIs is described in discover-https. </del>  2.1.

Reviewer comments:
Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,

Revised text:
An error on the HTTP/2.0 session.  <ins> A bi-directional flow of frames across a virtual channel within the HTTP/2.0 session. </ins> An error on the individual HTTP/2.0 stream. 2.  <ins> HTTP/2.0 uses the same "http:" and "https:" URI schemes used by HTTP/1.1.  As a result, implementations processing requests for a target resource URIs like "http://example.org/foo" or "https://example.com/bar" are required to first discover whether the upstream server (the immediate peer to which the client wishes to establish a connection) supports HTTP/2.0. </ins>  <ins> The means by which support for HTTP/2.0 is determined is different for "http" and "https" URIs.  Discovery for "https:" URIs is described in discover-https.  Discovery for "http" URIs is described here. </ins> 2.1.
Original text:
3.1. <del> The HTTP/2.0 session runs atop TCP (RFC0793).  The client is the TCP connection initiator. </del>  HTTP/2.0 connections are persistent.  That is, for best performance, <del> it is expected that clients will not close connections until the user navigates away from all Web pages referencing a connection, or until the server closes the connection.  Servers are encouraged to leave connections open for as long as possible, but can terminate idle connections if necessary.  When either endpoint closes the transport- level connection, it MUST first send a GOAWAY frame so that the endpoints can reliably determine if messages were processed beforehand. </del>  3.2. <del> The first data sent on an HTTP/2.0 session - after opening a TCP connection and performing either an HTTP/1.1 Upgrade or TLS handshake - is a session header. The session header provides a final confirmation that both peers agree to use the HTTP/2.0 protocol.  The SETTINGS frame ensures that client or server configuration is known as quickly as possible. </del>  The client session header is a sequence of 25 octets (in hex notation)

Reviewer comments:
Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,

Revised text:
3.1.  <ins> The HTTP/2.0 session is an Application Level protocol running on top of a TCP connection (RFC0793).  The client is the TCP connection initiator. </ins> HTTP/2.0 connections are persistent.  That is, for best performance,  <ins> it is expected a clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page), or until the server closes the connection. Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the transport-level TCP connection, the terminating endpoint MUST first send a GOAWAY frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </ins> 3.2.  <ins> Upon establishment of a TCP connection and determination that HTTP/2.0 will be used by both peers to communicate, each endpoint MUST send a session header as a final confirmation and to establish the default parameters for the HTTP/2.0 session. </ins> The client session header is a sequence of 25 octets (in hex notation)
Original text:
to process further frames.  Note that this does not address the concerns raised in TALKING. <del> The server session header is a SETTINGS.  The server sends the server session header (i.e., a SETTINGS frame) as the first frame in a new session. </del>  <del> The client sends requests immediately after sending the session header, without waiting to receive a server session header.  This ensures that confirming session headers does not add latency. </del>  <del> Both clients and servers MUST close the connection if it does not begin with a valid session header.  A GOAWAY MAY be omitted if it is clear that the peer is not using HTTP/2.0. </del>  3.3. <del> Once the connection is established, clients and servers exchange HTTP/2.0 frames.  Frames are the basic unit of communication. </del>  3.3.1.

Reviewer comments:
Multiple editorial commits....
Just an fyi... I have additional pending editorial edits, some of which are a bit more extensive. I will hold off committing them until this pull request is processed.
Ok, try now...
NAME - please don't do ANY reformatting in pull requests; we need to be able to precisely identify changes and their provenance. Thanks,

Revised text:
to process further frames.  Note that this does not address the concerns raised in TALKING.  <ins> The server session header consists of just a SETTINGS that MUST be the first frame the server sends in the HTTP/2.0 session. </ins>  <ins> In order to avoid unnecessary latency, clients are permitted to send additional frames to the server immediately after sending the client session header, without waiting to receive the server session header. However, it is important to note that the server session header SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. </ins>  <ins> Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid session header.  A GOAWAY MAY be omitted if it is clear that the peer is not using HTTP/2.0. </ins> 3.3.  <ins> Once the HTTP/2.0 session is established, clients and servers can begin exchanging frames. </ins> 3.3.1.
Original text:
A client that makes a request to an "https" URI uses TLS12 with the TLS-ALPN. <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. </del>  Once TLS negotiation is complete, both the client and the server MUST send a ConnectionHeader.

Reviewer comments:
Moves considerations of defining an ALPN token for a non-TLS-based protocol to 3.1. Changes "token" to "protocol identifier" in 3.3.

Revised text:
A client that makes a request to an "https" URI uses TLS12 with the TLS-ALPN.  <ins> HTTP/2 over TLS uses the "h2" protocol identifier.  The "h2c" protocol identifier MUST NOT be sent by a client or selected by a server; the "h2c" protocol identifier describes a protocol that does not use TLS. </ins> Once TLS negotiation is complete, both the client and the server MUST send a ConnectionHeader.
Original text:
HeaderBlock. The HEADERS frame can include padding.  Padding fields and flags are <del> identical to those defined for DATA. </del>  Prioritization information in a HEADERS frame is logically equivalent to a separate

Reviewer comments:
LGTM
Merged by RFC editor.
This wasn't obvious, but all descriptions of padding reference DATA: However, this is subtly wrong, as NAME notes. The actual text should be:

Revised text:
HeaderBlock. The HEADERS frame can include padding.  Padding fields and flags are  <ins> identical to those defined for DATA.  Padding that exceeds the size remaining for the header block fragment MUST be treated as a . </ins> Prioritization information in a HEADERS frame is logically equivalent to a separate
Original text:
6.3. The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can <del> be sent at any time for any stream, including idle or closed streams. </del>  The payload of a PRIORITY frame contains the following fields:

Reviewer comments:
This was confusing a few people who weren't clear if the prohibition on frame sending for CONTINUATION trumped this or not. This isn't a perfect fix, but it should be enough.
LGTM
Merged by RFC editor.

Revised text:
6.3. The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can  <ins> be sent in any stream state, including idle or closed streams. </ins> The payload of a PRIORITY frame contains the following fields:
Original text:
followed by the new maximum size, represented as an integer with a 5-bit prefix (see integer.representation). <del> The new maximum size MUST be lower than or equal to the last value of the maximum size of the dynamic table.  A value that exceeds this </del>  limit MUST be treated as a decoding error.  In HTTP/2, this limit is the last value of the SETTINGS_HEADER_TABLE_SIZE parameter (see HTTP2) received from the decoder and acknowledged by the encoder (see

Reviewer comments:
This is a minimal proposal for solving .
LGTM
Lgtm as well. On Mar 17, 2015 9:47 AM, "Martin Thomson" EMAIL wrote:

Revised text:
followed by the new maximum size, represented as an integer with a 5-bit prefix (see integer.representation).  <ins> The new maximum size MUST be lower than or equal to the limit determined by the protocol using HPACK.  A value that exceeds this </ins> limit MUST be treated as a decoding error.  In HTTP/2, this limit is the last value of the SETTINGS_HEADER_TABLE_SIZE parameter (see HTTP2) received from the decoder and acknowledged by the encoder (see
Original text:
The HEADERS frame (type=0x1) is used to StreamStates, and additionally carries a header block fragment.  HEADERS frames can be <del> sent on a stream in the "open" or "half closed (remote)" states. </del>  The HEADERS frame payload has the following fields:

Reviewer comments:
LGTM
Merged by RFC editor.
Minor bug that needs to be tracked... I assume the text in section 6.2 needs to be modified to add "idle"?

Revised text:
The HEADERS frame (type=0x1) is used to StreamStates, and additionally carries a header block fragment.  HEADERS frames can be  <ins> sent on a stream in the "idle", "reserved (local)", "open" or "half closed (remote)" states. </ins> The HEADERS frame payload has the following fields:
Original text:
The PUSH_PROMISE frame defines the following flags: <del> PUSH_PROMISE frames MUST be associated with a peer-initiated stream that is in either the "open" or "half closed (remote)" state.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is </del>  associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type

Reviewer comments:
This makes it clearer that they can't be sent otherwise.
LGTM
Merged by RFC editor.
has the following clarification added in draft 17: Should this be instead of ? If not I think we have an inconsistency with which has the following for the section:
NAME - Ping.
This is merely a problem with perspective. As in, there is none. I can provide that thusly: Does that work?
This is an improvement. I'm not sure if we can avoid it but it is a bit confusing with respect to :
I don't think that's a problem. The (remote) peer isn't sending, but the (local) peer can.
Agreed. Ship it :) Thanks!

Revised text:
The PUSH_PROMISE frame defines the following flags:  <ins> PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that is in either the "open" or "half closed (remote)" state.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is </ins> associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type
Original text:
The server session header consists of just a SETTINGS that MUST be the first frame the server sends in the HTTP/2.0 session. <del> In order to avoid unnecessary latency, clients are permitted to send </del>  additional frames to the server immediately after sending the client session header, without waiting to receive the server session header. <del> However, it is important to note that the server session header </del>  SETTINGS frame might include parameters that necessarily alter how a <del> client is expected to communicate with the server. </del>  Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid session header.  A GOAWAY MAY be omitted

Reviewer comments:
Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.

Revised text:
The server session header consists of just a SETTINGS that MUST be the first frame the server sends in the HTTP/2.0 session.  <ins> To avoid unnecessary latency, clients are permitted to send </ins> additional frames to the server immediately after sending the client session header, without waiting to receive the server session header.  <ins> It is important to note, however, that the server session header </ins> SETTINGS frame might include parameters that necessarily alter how a  <ins> client is expected to communicate with the server.  Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. </ins> Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid session header.  A GOAWAY MAY be omitted
Original text:
3.3.1. <del> HTTP/2.0 frames share a common format, consisting of 8 byte of header with between 0 and 65535 bytes of data. </del>  The fields of the frame header are defined as: <del> The 16-bit length of the frame data in bytes.  The length of the frame header is not included. </del>  The 8-bit type of the frame.  The frame type determines how the remainder of the frame header and data are interpreted.

Reviewer comments:
Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.

Revised text:
3.3.1.  <ins> HTTP/2.0 frames share a common base format consisting of an 8-byte header followed by 0 to 65535 bytes of data. </ins> The fields of the frame header are defined as:  <ins> The length of the frame data expressed as an unsigned, 16-bit integer.  The 8 bytes of the frame header are not included. </ins> The 8-bit type of the frame.  The frame type determines how the remainder of the frame header and data are interpreted.
Original text:
FINAL flag is sent.  The active sender on the stream MUST be prepared to receive frames after closing the stream. <del> Either the peer can send a RST_STREAM control frame at any time to </del>  terminate an active stream.  RST_STREAM contains an error code to indicate the reason for termination.  A RST_STREAM indicates that the sender will transmit no further data on the stream and that

Reviewer comments:
Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.

Revised text:
FINAL flag is sent.  The active sender on the stream MUST be prepared to receive frames after closing the stream.  <ins> Either peer can send a RST_STREAM control frame at any time to </ins> terminate an active stream.  RST_STREAM contains an error code to indicate the reason for termination.  A RST_STREAM indicates that the sender will transmit no further data on the stream and that
Original text:
It is possible that the GOAWAY will not be reliably received by the receiving endpoint.  In the event of a session error, GOAWAY only provides a best-effort attempt to communicate with the peer about why <del> the session is going down. </del>  An endpoint can end a session at any time.  In particular, an endpoint MAY choose to treat a stream error as a session error if the

Reviewer comments:
Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.

Revised text:
It is possible that the GOAWAY will not be reliably received by the receiving endpoint.  In the event of a session error, GOAWAY only provides a best-effort attempt to communicate with the peer about why  <ins> the session is being terminated. </ins> An endpoint can end a session at any time.  In particular, an endpoint MAY choose to treat a stream error as a session error if the
Original text:
3.3. <del> A client that makes a request to an "https" URI uses TLS12 with the </del>  TLS-ALPN. HTTP/2 over TLS uses the "h2" protocol identifier.  The "h2c"

Reviewer comments:
A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).

Revised text:
3.3.  <ins> A client that makes a request to an "https" URI uses TLS13 with the </ins> TLS-ALPN. HTTP/2 over TLS uses the "h2" protocol identifier.  The "h2c"