jiebi/TextFlow huggingface dataset:
Original text:
octets associated with a stream.  One or more DATA frames are used, for instance, to carry HTTP request or response payloads. <del> The DATA frame does not define any type-specific flags. </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:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Revised text:
octets associated with a stream.  One or more DATA frames are used, for instance, to carry HTTP request or response payloads.  <ins> The DATA frame defines the following flags: Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Bit 2 is reserved for future use. </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:
The payload of a PRIORITY frame contains a single reserved bit and a 31-bit priority. <del> The PRIORITY frame does not define any type-specific flags. </del>  The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the

Reviewer comments:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Revised text:
The payload of a PRIORITY frame contains a single reserved bit and a 31-bit priority.  <ins> The PRIORITY frame does not define any flags. </ins> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the
Original text:
values for parameters whose values have already been established. Only the most recent value provided setting value applies. <del> The SETTINGS frame does not have any frame specific flags. </del>  SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a settings frame MUST be zero.  If an

Reviewer comments:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Revised text:
values for parameters whose values have already been established. Only the most recent value provided setting value applies.  <ins> The SETTINGS frame does not define any flags. </ins> SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a settings frame MUST be zero.  If an
Original text:
payload.  PING responses SHOULD given higher priority than any other frame. <del> The PING frame defines one type-specific flag: </del>  <del> Bit 2 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:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Revised text:
payload.  PING responses SHOULD given higher priority than any other frame.  <ins> The PING frame defines the following flags: </ins>  <ins> Bit 1 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:
After sending a GOAWAY frame, the sender can ignore frames for new streams. <del> The GOAWAY frame does not define any type-specific flags. </del>  The GOAWAY frame applies to the connection, not a specific stream. The stream identifier MUST be zero.

Reviewer comments:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Revised text:
After sending a GOAWAY frame, the sender can ignore frames for new streams.  <ins> The GOAWAY frame does not define any flags. </ins> The GOAWAY frame applies to the connection, not a specific stream. The stream identifier MUST be zero.
Original text:
Any number of HEADERS frames can may be sent on an existing stream at any time. <del> Additional type-specific flags for the HEADERS frame are: </del>  The END_HEADERS bit indicates that this frame contains the entire payload necessary to provide a complete set of headers.

Reviewer comments:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Revised text:
Any number of HEADERS frames can may be sent on an existing stream at any time.  <ins> The HEADERS frame defines the following flags: Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Bit 2 is reserved for future use. </ins> The END_HEADERS bit indicates that this frame contains the entire payload necessary to provide a complete set of headers.
Original text:
respond with a StreamErrorHandler or ConnectionErrorHandler of type FLOW_CONTROL_ERROR if it is unable accept a frame. <del> The following additional flags are defined for the WINDOW_UPDATE frame: </del>  <del> Bit 2 being set indicates that flow control for the identified </del>  stream or connection has been ended; subsequent frames do not need to be flow controlled.

Reviewer comments:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Revised text:
respond with a StreamErrorHandler or ConnectionErrorHandler of type FLOW_CONTROL_ERROR if it is unable accept a frame.  <ins> The WINDOW_UPDATE frame defines the following flags: </ins>  <ins> Bit 1 being set indicates that flow control for the identified </ins> stream or connection has been ended; subsequent frames do not need to be flow controlled.
Original text:
3.3. <del> Once the HTTP/2.0 connection is established, clients and servers can begin exchanging frames. </del>  3.3.1. <del> HTTP/2.0 frames share a common base format consisting of an 8-byte header followed by 0 to 65535 bytes of data. </del>  The fields of the frame header are defined as:

Reviewer comments:
As discussed in the interim... (I had previously submitted this in a batch against the Layering branch... redoing against the Master)
Looks good for the most part, consider the comments as advisory only.

Revised text:
3.3.  <ins> Once the HTTP/2.0 connection is established, endpoints can begin exchanging frames. </ins> 3.3.1.  <ins> All frames share a common base format consisting of an 8-byte header followed by 0 to 65,535 octets of payload data. </ins> The fields of the frame header are defined as:
Original text:
3.3.2. <del> Implementations with limited resources might not be capable of processing large frame sizes.  Such implementations MAY choose to place additional limits on the maximum frame size.  However, all implementations MUST be capable of receiving and processing frames containing at least 8192 octets of data. An implementation MUST terminate a stream immediately if it is unable to process a frame due it's size.  This is done by sending an RST_STREAM containing the FRAME_TOO_LARGE error code. </del>  3.4.

Reviewer comments:
As discussed in the interim... (I had previously submitted this in a batch against the Layering branch... redoing against the Master)
Looks good for the most part, consider the comments as advisory only.

Revised text:
3.3.2.  <ins> The maximum amount of payload data any frame can contain varies by frame type and use.  The absolute maximum amount of payload data any individual frame can contain is 65,535 octets.  All implementations SHOULD be capable of receiving and minimally processing frames up to this size. Certain frame types, such as PING (see PING), impose strict limits on the amount of payload data allowed.  Likewise, additional size limits can be set by specific application uses.  For instance, individual DATA and HEADERS frames used to express HTTP request and response messages (see HTTPLayer) are not permitted to exceed 16,383 octets of payload.  Sending endpoints MUST NOT exceed such limits. If an endpoint is unable to process a frame due to the payload size, or if the size exceeds a strictly defined limit, the endpoint MUST send a FRAME_TOO_LARGE error.  If the frame stream identifier is 0x0, this code MUST be sent as a connection error.  If the stream identifier is anything other than 0x0, it is sent as a stream error. </ins> 3.4.
Original text:
The following terms are used:  The endpoint initiating the HTTP connection. A transport-level connection between two endpoints.

Reviewer comments:
:Client advertising settings during Upgrade dance URL
I assume that this header field is hop-by-hop in the HTTP/1.1 sense and should appear in the Connection header field.
Ooops, yes! Just checked that in.
This issue is to track whether the client should advertise its settings (e.g. contents of SETTINGS frame) as part of the Upgrade GET (e.g. as HTTP/1.1 headers in the GET request). Normally, the first HTTP/2.0 frame the client emits is the SETTINGS frame. This means the server will receive the client's settings before getting the SYNSTREAM from the client. However, in the Upgrade Dance the server receives the GET and has to respond with a 101 HTTP/1.1 response followed by the HTTP/2.0 SYNREPLY. The ugliness here is that the server will be in a situation where it has to send the SYN_REPLY (and possibly DATA frames and possibly start push streams) without knowing the client's settings. This means the server may blow the client’s flow control buffers, or emit a pushed stream even though the client is incapable of processing pushed streams, etc. If we include the settings as part of the initial Upgrade GET then 1) Server receives the pre-requisite initials settings and the initial GET request in a single package. Makes life simpler. 2) Brings us to parity with the SSL route where the server will have the cilent's SETTINGS before it starts working on the initial request.
Discussed at SF Interim; targetting 1st implementation draft. Gabriel to make proposal.
Addressed via "HTTP2-Settings Header Field" section.

Revised text:
The following terms are used: <ins> The URL- and filename-safe Base64 encoding described in RFC4648, Section 5, with the (non URL- safe) '=' padding characters omitted, as permitted by RFC 4648, Section 3.2. </ins> The endpoint initiating the HTTP connection. A transport-level connection between two endpoints.
Original text:
An initial set of settings registrations can be found in SettingValues. 

Reviewer comments:
:Client advertising settings during Upgrade dance URL
I assume that this header field is hop-by-hop in the HTTP/1.1 sense and should appear in the Connection header field.
Ooops, yes! Just checked that in.
This issue is to track whether the client should advertise its settings (e.g. contents of SETTINGS frame) as part of the Upgrade GET (e.g. as HTTP/1.1 headers in the GET request). Normally, the first HTTP/2.0 frame the client emits is the SETTINGS frame. This means the server will receive the client's settings before getting the SYNSTREAM from the client. However, in the Upgrade Dance the server receives the GET and has to respond with a 101 HTTP/1.1 response followed by the HTTP/2.0 SYNREPLY. The ugliness here is that the server will be in a situation where it has to send the SYN_REPLY (and possibly DATA frames and possibly start push streams) without knowing the client's settings. This means the server may blow the client’s flow control buffers, or emit a pushed stream even though the client is incapable of processing pushed streams, etc. If we include the settings as part of the initial Upgrade GET then 1) Server receives the pre-requisite initials settings and the initial GET request in a single package. Makes life simpler. 2) Brings us to parity with the SSL route where the server will have the cilent's SETTINGS before it starts working on the initial request.
Discussed at SF Interim; targetting 1st implementation draft. Gabriel to make proposal.
Addressed via "HTTP2-Settings Header Field" section.

Revised text:
An initial set of settings registrations can be found in SettingValues. <ins> 8.4. 8.4.1. This section describes a header field for registration in the Permanent Message Header Field Registry.  RFC3864 HTTP2-Settings http standard IETF RFC XXXX (this document) This header field is only used by the client in the Upgrade-based negotiation. The HTTP2-Settings header field is used in the Upgrade-based negotiation by the client.  It is sent from the client to the server to provide the payload for its SETTINGS frame in anticipation of the server responding with HTTP/2.0 frames. The HTTP2-Settings header field MUST NOT appear more than once in an HTTP request and MUST NOT appear at all in an HTTP response. </ins>
Original text:
From this state either peer can send a frame with a END_STREAM flag set, which causes the stream to transition into one of the <del> "half closed" states: a client sending a END_STREAM flag causes the stream state to become "half closed (client)"; a server sending a END_STREAM flag causes the stream state to become "half closed (server)". </del>  An endpoint can send RST_STREAM from this state, causing it to transition immediately to "closed".

Reviewer comments:
half closed (client/server) is no longer used. :scheme header MUST include HTTP Request
NAME The fixes of the commit of 73dce91fcccecce7079d7ccf6294e80350d5ce19 were somehow lost after ea5abcf90460dc300b94eb27d82162f56a1dc526 . I'm not sure why it happened without conflicting. Please fix them by your hand.
Will do. It's easy enough to fix.

Revised text:
From this state either peer can send a frame with a END_STREAM flag set, which causes the stream to transition into one of the  <ins> "half closed" states: an endpoint sending a END_STREAM flag causes the stream state to become "half closed (local)"; an endpoind receiving a END_STREAM flag causes the stream state to become "half closed (remote)". </ins> An endpoint can send RST_STREAM from this state, causing it to transition immediately to "closed".
Original text:
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 Upgrade header field identifying HTTP/2.0.  The HTTP/1.1 request MUST <del> include an Http2SettingsHeader header field. </del>  Requests that contain a request entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that

Reviewer comments:
I think this is strictly an editorial clarification, not a technical change, but something that came up in discussions within the team. If there's any question about that, feel free to push it back and we'll discuss on-list.
This looks like , sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too.
Similar issue, different layer…. is talking about multiple instances of the same setting value in a single SETTINGS frame. This commit is talking about multiple instances of the “HTTP2-Settings” header in an HTTP/1.1 request that’s offering Upgrade. From: martinthomson [mailto:EMAIL] Sent: Thursday, July 18, 2013 3:49 PM To: http2/http2-spec Cc: Mike Bishop Subject: Re: [http2-spec] Clarify no duplicate instances of HTTP2-Settings () This looks like URL, sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too. — Reply to this email directly or view it on URL
Ahh, I don't see this as a big deal, since "a header field" and "exactly one header field" seem equivalent to me. I'll pull it in.

Revised text:
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 Upgrade header field identifying HTTP/2.0.  The HTTP/1.1 request MUST  <ins> include exactly one Http2SettingsHeader header field. </ins> Requests that contain a request entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that
Original text:
3.2.1. <del> A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include an "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the </del>  HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present.

Reviewer comments:
I think this is strictly an editorial clarification, not a technical change, but something that came up in discussions within the team. If there's any question about that, feel free to push it back and we'll discuss on-list.
This looks like , sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too.
Similar issue, different layer…. is talking about multiple instances of the same setting value in a single SETTINGS frame. This commit is talking about multiple instances of the “HTTP2-Settings” header in an HTTP/1.1 request that’s offering Upgrade. From: martinthomson [mailto:EMAIL] Sent: Thursday, July 18, 2013 3:49 PM To: http2/http2-spec Cc: Mike Bishop Subject: Re: [http2-spec] Clarify no duplicate instances of HTTP2-Settings () This looks like URL, sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too. — Reply to this email directly or view it on URL
Ahh, I don't see this as a big deal, since "a header field" and "exactly one header field" seem equivalent to me. I'll pull it in.

Revised text:
3.2.1.  <ins> A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the </ins> HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present.
Original text:
3.2.1. <del> A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present. </del>  The content of the "HTTP2-Settings" header field is the payload of a

Reviewer comments:
Fixed the word "client" to "request" on "HTTP2-Settings Header Field".

Revised text:
3.2.1.  <ins> A request that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present. </ins> The content of the "HTTP2-Settings" header field is the payload of a
Original text:
represented either literally or as a reference to an entry of the header table.  The header value is represented literally. <del> Three different literal representations are provided: </del>  A literal representation that does not add the header to the header table (see literal.header.without.indexing). <del> A literal representation that adds the header at the end of the header table (see literal.header.with.incremental.indexing). A literal representation that uses the header to replace an existing entry of the header table (see literal.header.with.substitution.indexing). </del>  The indexed representation defines a header as a reference in the header table (see indexed.header.representation).

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 either literally or as a reference to an entry of the header table.  The header value is represented literally.  <ins> Two different literal representations are provided: </ins> A literal representation that does not add the header to the header table (see literal.header.without.indexing).  <ins> A literal representation that adds the header at the beginning of the header table (see literal.header.with.incremental.indexing). </ins> The indexed representation defines a header as a reference in the header table (see indexed.header.representation).
Original text:
or by replacing an existing one.  Before doing such a modification, it has to be ensured that the header table size will stay lower than or equal to the SETTINGS_HEADER_TABLE_SIZE limit (see <del> parameter.negotiation).  To achieve this, repeatedly, the first entry </del>  of the header table is removed, until enough space is available for the modification.

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:
or by replacing an existing one.  Before doing such a modification, it has to be ensured that the header table size will stay lower than or equal to the SETTINGS_HEADER_TABLE_SIZE limit (see  <ins> parameter.negotiation).  To achieve this, repeatedly, the last entry </ins> of the header table is removed, until enough space is available for the modification.