jiebi/TextFlow huggingface dataset:
Original text:
before being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a generic HTTP server application. <del> The Cookie header field MAY be split using a zero octet (0x0), as defined in HeaderOrdering.  When decoding, zero octets MUST be replaced with the cookie delimiter ("; "). 8.1.2.5. </del>  A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames, but is otherwise invalid due to the

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:
before being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a generic HTTP server application.  <ins> 8.1.2.6. </ins> A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames, but is otherwise invalid due to the
Original text:
at the index corresponding to the number of entries in the header table. <del> The header table is initially empty. </del>  The header table can contain duplicate entries.  Therefore, duplicate entries MUST NOT be treated as an error by a decoder.

Reviewer comments:
Looks like I caught some trailing whitespace at the same time.
The trailing whitespace came from an automatically generated part of the spec and will reappear if I ever re-generate the examples. In addition, it really should be here ;-).

Revised text:
at the index corresponding to the number of entries in the header table.  <ins> The header table is initially empty.  Entries are added as each header block is decompressed. </ins> The header table can contain duplicate entries.  Therefore, duplicate entries MUST NOT be treated as an error by a decoder.
Original text:
Abstract <del> This specification describes an optimized expression of the syntax of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more </del>  efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection.  It also introduces

Reviewer comments:
Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.

Revised text:
Abstract  <ins> This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more </ins> efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection.  It also introduces
Original text:
are used in support of other HTTP/2 features. Multiplexing of requests is achieved by having each HTTP request- <del> response exchanged assigned to a single StreamsLayer.  Streams are largely independent of each other, so a blocked or stalled request does not prevent progress on other requests. </del>  Flow control and prioritization ensure that it is possible to <del> properly use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. </del>  StreamPriority ensures that limited resources can be directed to the <del> most important requests first. </del>  HTTP/2 adds a new interaction mode, whereby a server can PushResources.  Server push allows a server to speculatively send a

Reviewer comments:
Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.

Revised text:
are used in support of other HTTP/2 features. Multiplexing of requests is achieved by having each HTTP request-  <ins> response exchange associated with its own StreamsLayer.  Streams are largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams. </ins> Flow control and prioritization ensure that it is possible to  <ins> efficiently use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. </ins> StreamPriority ensures that limited resources can be directed to the  <ins> most important streams first. </ins> HTTP/2 adds a new interaction mode, whereby a server can PushResources.  Server push allows a server to speculatively send a
Original text:
using frames and streams. While some of the frame and stream layer concepts are isolated from <del> HTTP, the intent is not to define a completely generic framing layer. The framing and streams layers are tailored to the needs of the HTTP protocol and server push. </del>  2.2.

Reviewer comments:
Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.

Revised text:
using frames and streams. While some of the frame and stream layer concepts are isolated from  <ins> HTTP, this specification does not define a completely generic framing layer.  The framing and streams layers are tailored to the needs of the HTTP protocol and server push. </ins> 2.2.
Original text:
The endpoint initiating the HTTP/2 connection. <del> A transport-level connection between two endpoints. </del>  An error that affects the entire HTTP/2 connection.

Reviewer comments:
Editorial suggestions for WGLC. I don't think there's anything controversial or semantically significant here, but please have a look over it before accepting.

Revised text:
The endpoint initiating the HTTP/2 connection.  <ins> A transport-layer connection between two endpoints. </ins> An error that affects the entire HTTP/2 connection.
Original text:
8.2. HTTP/2 allows a server to pre-emptively send (or "push") responses <del> (along with corresponding requests) to a client in association with a previous client-initiated request.  This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. </del>  Pushing additional message exchanges in this fashion is optional, and is negotiated between individual endpoints.  The setting can be set to 0 to indicate that server push is disabled.  Because server push is effectively hop-by-hop, an intermediary could receive pushes from the server and choose not to forward them on to the client.  In other words, how to make use of the pushed

Reviewer comments:
I think the section could benefit from rearrangement some after this, but I'll leave that until later.
Once that's done, I'll have a look to see if there is anything that can be done to improve the section structure. The expanded material might need a new section heading and maybe some re-framing. Suggestions are, as always, very welcome.
I'll tweak this to soften the SHOULD and MAY.

Revised text:
8.2. HTTP/2 allows a server to pre-emptively send (or "push") responses  <ins> (along with corresponding "promised" requests) to a client in association with a previous client-initiated request.  This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. </ins> Pushing additional message exchanges in this fashion is optional, and is negotiated between individual endpoints.  The setting can be set to 0 to indicate that server push is disabled. <ins> Promised requests MUST be cacheable (see RFC7231), MUST be safe (see RFC7231) and MUST NOT include a request body.  Clients that receive a promised request that is not cacheable, unsafe or that includes a request body MUST reset the stream with a StreamErrorHandler of type . Pushed responses that are cacheable (see RFC7234) SHOULD be stored by the client, if it implements a HTTP cache.  Such responses MAY be 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. Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache.  They MAY be made available to the application separately. </ins> Because server push is effectively hop-by-hop, an intermediary could receive pushes from the server and choose not to forward them on to the client.  In other words, how to make use of the pushed
Original text:
. <del> A server can only push responses that are cacheable (see RFC7234); promised requests MUST be safe (see RFC7231) and MUST NOT include a request body. </del> 8.2.1. Server push is semantically equivalent to a server responding to a

Reviewer comments:
I think the section could benefit from rearrangement some after this, but I'll leave that until later.
Once that's done, I'll have a look to see if there is anything that can be done to improve the section structure. The expanded material might need a new section heading and maybe some re-framing. Suggestions are, as always, very welcome.
I'll tweak this to soften the SHOULD and MAY.

Revised text:
.  8.2.1. Server push is semantically equivalent to a server responding to a
Original text:
frame.  SettingsSync is not necessary, since a 101 response serves as implicit acknowledgment.  Providing these values in the Upgrade <del> request ensures that the protocol does not require default values for the above SETTINGS parameters, and gives a client an opportunity to provide other parameters prior to receiving any frames from the server. </del>  3.3. <del> A client that makes a request to an "https" URI without prior knowledge about support for HTTP/2 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.

Reviewer comments:
A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.

Revised text:
frame.  SettingsSync is not necessary, since a 101 response serves as implicit acknowledgment.  Providing these values in the Upgrade  <ins> request gives a client an opportunity to provide parameters prior to receiving any frames from the server. </ins> 3.3.  <ins> A client that makes a request to an "https" URI 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:
frame (WINDOW_UPDATE).  This document does not stipulate how a receiver decides when to send this frame or the value that it <del> sends.  Nor does it specify how a sender chooses to send packets. </del>  Implementations are able to select any algorithm that suits their needs.

Reviewer comments:
A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.

Revised text:
frame (WINDOW_UPDATE).  This document does not stipulate how a receiver decides when to send this frame or the value that it  <ins> sends, nor does it specify how a sender chooses to send packets. </ins> Implementations are able to select any algorithm that suits their needs.
Original text:
5.3.2. <del> All dependent streams are allocated an integer weight between 1 to </del>  256 (inclusive). Streams with the same parent SHOULD be allocated resources

Reviewer comments:
A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.

Revised text:
5.3.2.  <ins> All dependent streams are allocated an integer weight between 1 and </ins> 256 (inclusive). Streams with the same parent SHOULD be allocated resources
Original text:
A HeaderBlock. <del> Padding octets. </del>  The HEADERS frame defines the following flags:

Reviewer comments:
A couple nitpicky things that jumped out at me in another readthrough. 3.2.1: Says that the SETTINGS parameters don't need defaults because of HTTP2-Settings, but they have defaults. Removing this claim. 3.3: Says that ALPN is used for HTTPS if you don't have prior knowledge, but 3.4 says you have to use ALPN even if you do have prior knowledge. Removing the caveat in 3.3 to reconcile. 5.1: Allowing WINDOW_UPDATE to be send in reserved (remote) state. This has been discussed in-person and on-list as a reasonable client strategy (low initial window, unchoke the pushes you want), but per the current text this is actually prohibited until after receiving the HEADERS frame. 5.2.1: Fixing sentence fragment. 5.3.2: Possibly just a personal/regional style, but from/to or between/and works for me; between/to doesn't. 6.1 and 6.2 use different definitions of the padding field. Copied 6.1's to 6.2.
Thanks Mike.

Revised text:
A HeaderBlock.  <ins> Padding octets that contain no application semantic value. Padding octets MUST be set to zero when sending and ignored when receiving. </ins> The HEADERS frame defines the following flags:
Original text:
stream risks being ignored due to the peer having discarded priority state information for that stream.  6.4. The RST_STREAM frame (type=0x3) allows for abnormal termination of a

Reviewer comments:
If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?

Revised text:
stream risks being ignored due to the peer having discarded priority state information for that stream. <ins> A PRIORITY frame with a length other than 5 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.4. The RST_STREAM frame (type=0x3) allows for abnormal termination of a
Original text:
.  6.5. The SETTINGS frame (type=0x4) conveys configuration parameters that

Reviewer comments:
If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?

Revised text:
. <ins> A RST_STREAM frame with a length other than 4 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.5. The SETTINGS frame (type=0x4) conveys configuration parameters that
Original text:
.  6.5.1. The payload of a SETTINGS frame consists of zero or more parameters,

Reviewer comments:
If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?

Revised text:
. <ins> A SETTINGS frame with a length other than a multiple of 6 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.5.1. The payload of a SETTINGS frame consists of zero or more parameters,
Original text:
frame toward the flow control window, if the receiver does not, the flow control window at sender and receiver can become different.  6.9.1. Flow control in HTTP/2 is implemented using a window kept by each

Reviewer comments:
If an http2 implementation receives a frame with an unexpectedly large size, what should it do? As one example, a WINDOW_UPDATE should be 4 bytes. Or should it be at least 4 bytes? The Extending HTTP/2 notes at URL aren't clear about whether an unexpectedly long frame is okay. The closest I can find is: "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. " But I can't find a definition of an "extensible protocol element". It seems that the spirit of Section 5.5 would be to permit overly long frames.
I forgot to mention: there is FRAMESIZEERROR, but it only says: "If a frame size exceeds any defined limit, or is too small to contain mandatory frame data, the endpoint MUST send a FRAMESIZEERROR error." But only PING and SETTINGS mention it or a limit. What is the intended behavior for PRIORITY, RSTSTREAM and WINDOWUPDATE?

Revised text:
frame toward the flow control window, if the receiver does not, the flow control window at sender and receiver can become different. <ins> A WINDOW_UPDATE frame with a length other than 4 octets MUST be treated as a ConnectionErrorHandler of type . </ins> 6.9.1. Flow control in HTTP/2 is implemented using a window kept by each
Original text:
4. <del> 4.1. </del> To limit the memory requirements on the decoder side, the dynamic table is constrained in size.  Protocols that use HPACK determine the maximum size of table that the encoder is permitted to use.  In HTTP/2, this value is determined by the SETTINGS_HEADER_TABLE_SIZE setting (see HTTP2).

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:
4.  To limit the memory requirements on the decoder side, the dynamic table is constrained in size. <ins> 4.1. 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. </ins> Protocols that use HPACK determine the maximum size of table that the encoder is permitted to use.  In HTTP/2, this value is determined by the SETTINGS_HEADER_TABLE_SIZE setting (see HTTP2).