jiebi/TextFlow huggingface dataset:
Original text:
delivery, leaving only request order and the delivery of responses as sources of timing variability. <del> Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. </del>  11.

Reviewer comments:
Values is correct in the first case, but the second should be "a value" by which it means "any value".
and 10.9: Please confirm that these instances of "value" should not be "values". Original: These include the value of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. Possibly: These include the values of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on secret values is the best defense against any form of timing attack.
These should both be "values".
Values is correct in the first case, but the second should be "a value" by which it means "any value".

Revised text:
delivery, leaving only request order and the delivery of responses as sources of timing variability.  <ins> Ensuring that processing time is not dependent on the value of a secret is the best defense against any form of timing attack. </ins> 11.
Original text:
The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the <del> recipient MUST respond with a StreamErrorHandler of type </del>  PROTOCOL_ERROR. 3.8.4.

Reviewer comments:
Error when stream identifier field is 0x0 is not stream error but connection error because it is impossible to send RST_STREAM of 0x0.

Revised text:
The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the  <ins> recipient MUST respond with a ConnectionErrorHandler of type </ins> PROTOCOL_ERROR. 3.8.4.
Original text:
The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the <del> recipient MUST respond with a StreamErrorHandler of type </del>  PROTOCOL_ERROR. The HEADERS frame changes the connection state as defined in

Reviewer comments:
Error when stream identifier field is 0x0 is not stream error but connection error because it is impossible to send RST_STREAM of 0x0.

Revised text:
The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the  <ins> recipient MUST respond with a ConnectionErrorHandler of type </ins> PROTOCOL_ERROR. The HEADERS frame changes the connection state as defined in
Original text:
The endpoint detected that its peer violated the flow control protocol. <del> The endpoint received a frame for an inactive stream. </del> The endpoint received a frame after a stream was half-closed. The endpoint received a frame that was larger than the maximum

Reviewer comments:
It is no longer used after d5a8faeaa605bdff7b96287d72913b4b742104cf
I've avoided renumbering of codes when removing things. We probably need to have a big renumber event at some point, but there is no harm in having gaps for now.
Thanks Martin. It makes it easier for us on the SPDY side :) On Wed Jun 12 2013 at 9:37:50 AM, martinthomson EMAIL wrote:
NAME I've updated the commit just to remove only the unused error code. Please don't forget to renumber others in the future.

Revised text:
The endpoint detected that its peer violated the flow control protocol.  The endpoint received a frame after a stream was half-closed. The endpoint received a frame that was larger than the maximum
Original text:
idle connection is still functional.  PING frames can be sent from any endpoint. <del> PING frames consist of an arbitrary, variable-length sequence of octets.  Receivers of a PING send a response PING frame with the PONG </del>  flag set and precisely the same sequence of octets back to the sender as soon as possible.

Reviewer comments:
As discussed in the interim, 8-byte PING frame, opaque octets that MUST be included regardless of whether they are used.

Revised text:
idle connection is still functional.  PING frames can be sent from any endpoint.  <ins> In addition to the frame header, PING frames MUST contain 8 additional octets of opaque data.  A sender can utilize this payload in any manner it wishes but MUST include the octets even if they are unused.  Receivers of a PING send a response PING frame with the PONG </ins> flag set and precisely the same sequence of octets back to the sender as soon as possible.
Original text:
part of the connection header. Prior to receiving a SETTINGS frame that sets a value for <del> SETTINGS_INITIAL_WINDOW_SIZE, a client can only use the default </del>  initial window size when sending flow controlled frames.  Similarly, the connection flow control window is set to the default initial window size until a WINDOW_UPDATE frame is received. A SETTINGS frame can alter the initial flow control window size for all current streams.  When the value of SETTINGS_INITIAL_WINDOW_SIZE <del> changes, a receiver MUST adjust the size of all flow control windows that it maintains by the difference between the new value and the old value. </del>  A change to SETTINGS_INITIAL_WINDOW_SIZE could cause the available space in a flow control window to become negative.  A sender MUST

Reviewer comments:
Curious why the connection flow control window initial size is 64K (65536 bytes) but the stream flow control window initial size is 65535 bytes. The negative flow control example (taken from the SPDY spec) states that the initial stream flow control window is 64K (the SPDY/3 value).
I have to stop trusting Will's edits. He, rightfully, challenged the use of SETTINGS to end connection-level flow control because WINDOW_UPDATE provided another way to do the same, and two ways to do the same thing is bad. I'll fix that up.

Revised text:
part of the connection header. Prior to receiving a SETTINGS frame that sets a value for  <ins> SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default </ins> initial window size when sending flow controlled frames.  Similarly, the connection flow control window is set to the default initial window size until a WINDOW_UPDATE frame is received. A SETTINGS frame can alter the initial flow control window size for all current streams.  When the value of SETTINGS_INITIAL_WINDOW_SIZE  <ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and the old value.  A SETTINGS frame cannot alter the connection flow control window. </ins> A change to SETTINGS_INITIAL_WINDOW_SIZE could cause the available space in a flow control window to become negative.  A sender MUST
Original text:
not obligated to maintain the available flow control window for streams that it is no longer sending on. <del> Flow control can be disabled for all streams or the connection using </del>  the SETTINGS_FLOW_CONTROL_OPTIONS setting.  An implementation that <del> does not wish to perform flow control can use this in the initial SETTINGS exchange. </del>  Flow control can be disabled for an individual stream or the overall connection by sending a WINDOW_UPDATE with the END_FLOW_CONTROL flag

Reviewer comments:
Curious why the connection flow control window initial size is 64K (65536 bytes) but the stream flow control window initial size is 65535 bytes. The negative flow control example (taken from the SPDY spec) states that the initial stream flow control window is 64K (the SPDY/3 value).
I have to stop trusting Will's edits. He, rightfully, challenged the use of SETTINGS to end connection-level flow control because WINDOW_UPDATE provided another way to do the same, and two ways to do the same thing is bad. I'll fix that up.

Revised text:
not obligated to maintain the available flow control window for streams that it is no longer sending on.  <ins> Flow control can be disabled for all streams on the connection using </ins> the SETTINGS_FLOW_CONTROL_OPTIONS setting.  An implementation that  <ins> does not wish to perform stream flow control can use this in the initial SETTINGS exchange. </ins> Flow control can be disabled for an individual stream or the overall connection by sending a WINDOW_UPDATE with the END_FLOW_CONTROL flag
Original text:
The payload of a PRIORITY frame contains a single reserved bit and a 31-bit priority.  The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type

Reviewer comments:
All other frame descriptions specify explicitly if the frame type does not have any type-specific flags. The PRIORITY frame description should do the same if there are no flags.

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 type-specific flags. </ins> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type
Original text:
An 8-bit field reserved for frame-type specific boolean flags. <del> The least significant bit (0x1) - the FINAL bit - is defined for all frame types as an indication that this frame is the last the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose.  Implementations MUST process the FINAL bit for all frames whose stream identifier field is not 0x0.  The FINAL bit MUST NOT be set on frames that use a stream identifier of 0. </del>  The remaining flags can be assigned semantics specific to the indicated frame type.  Flags that have no defined semantics for a

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
An 8-bit field reserved for frame-type specific boolean flags.  <ins> The least significant bit (0x1) - the END_STREAM bit - is defined for all frame types as an indication that this frame is the last the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Implementations MUST process the END_STREAM bit for all frames whose stream identifier field is not 0x0.  The END_STREAM bit MUST NOT be set on frames that use a stream identifier of 0. </ins> The remaining flags can be assigned semantics specific to the indicated frame type.  Flags that have no defined semantics for a
Original text:
3.4.3. <del> When an endpoint sends a frame for a stream with the FINAL flag set, the stream is considered to be half-closed for that endpoint. </del>  Subsequent frames MUST NOT be sent by that endpoint for the half closed stream for the remaining duration of the HTTP/2.0 connection. <del> When both endpoints have sent frames with the FINAL flag set, the stream is considered to be fully closed. </del>  If an endpoint receives additional frames for a stream that was previously half-closed by the sending peer, the recipient MUST respond with a StreamErrorHandler of type STREAM_CLOSED. An endpoint that has not yet half-closed a stream by sending the <del> FINAL flag can continue sending frames on the stream. </del>  It is not necessary for an endpoint to half-close a stream for which it has not sent any frames.  This allows endpoints to use fully

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
3.4.3.  <ins> When an endpoint sends a frame for a stream with the END_STREAM flag set, the stream is considered to be half-closed for that endpoint. </ins> Subsequent frames MUST NOT be sent by that endpoint for the half closed stream for the remaining duration of the HTTP/2.0 connection.  <ins> When both endpoints have sent frames with the END_STREAM flag set, the stream is considered to be fully closed. </ins> If an endpoint receives additional frames for a stream that was previously half-closed by the sending peer, the recipient MUST respond with a StreamErrorHandler of type STREAM_CLOSED. An endpoint that has not yet half-closed a stream by sending the  <ins> END_STREAM flag can continue sending frames on the stream. </ins> It is not necessary for an endpoint to half-close a stream for which it has not sent any frames.  This allows endpoints to use fully
Original text:
A stream that only has frames sent in one direction can be tentatively considered to be closed once a frame containing a <del> FINAL flag is sent.  The active sender on the stream MUST be </del>  prepared to receive frames after closing the stream. Either peer can send a RST_STREAM control frame at any time to

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
A stream that only has frames sent in one direction can be tentatively considered to be closed once a frame containing a  <ins> END_STREAM flag is sent.  The active sender on the stream MUST be </ins> prepared to receive frames after closing the stream. Either peer can send a RST_STREAM control frame at any time to
Original text:
single reserved bit and a 31-bit priority; see StreamPriority. HEADERS+PRIORITY uses the same flags as the HEADERS frame, except <del> that a HEADERS+PRIORITY frame with a CONTINUES bit MUST be followed by another HEADERS+PRIORITY frame.  See HEADERS for any flags. </del>  HEADERS+PRIORITY frames MUST be associated with a stream.  If a HEADERS+PRIORITY frame is received whose stream identifier field is

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
single reserved bit and a 31-bit priority; see StreamPriority. HEADERS+PRIORITY uses the same flags as the HEADERS frame, except  <ins> that a HEADERS+PRIORITY frame without the END_HEADERS flag set MUST be followed by another HEADERS+PRIORITY frame.  See HEADERS for any flags. </ins> HEADERS+PRIORITY frames MUST be associated with a stream.  If a HEADERS+PRIORITY frame is received whose stream identifier field is
Original text:
promised streams fully close as well. PUSH_PROMISE uses the same flags as the HEADERS frame, except that a <del> PUSH_PROMISE frame with a CONTINUES bit MUST be followed by another PUSH_PROMISE frame.  See HEADERS for any flags. </del>  Promised streams are not required to be used in order promised.  The PUSH_PROMISE only reserves stream identifiers for later use.

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
promised streams fully close as well. PUSH_PROMISE uses the same flags as the HEADERS frame, except that a  <ins> PUSH_PROMISE frame without the END_HEADERS flag set MUST be followed by another PUSH_PROMISE frame.  See HEADERS for any flags. </ins> Promised streams are not required to be used in order promised.  The PUSH_PROMISE only reserves stream identifiers for later use.
Original text:
Additional type-specific flags for the HEADERS frame are: <del> The CONTINUES bit indicates that this frame does not contain the entire payload necessary to provide a complete set of headers. </del>  The payload for a complete set of headers is provided by a <del> sequence of HEADERS frames, terminated by a HEADERS frame without the CONTINUES bit.  Once the sequence terminates, the payload of all HEADERS frames are concatenated and interpreted as a single </del>  block. <del> A HEADERS frame that includes a CONTINUES bit MUST be followed by a HEADERS frame for the same stream.  A receiver MUST treat the </del>  receipt of any other type of frame or a frame on a different stream as a ConnectionErrorHandler of type PROTOCOL_ERROR.

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
Additional type-specific flags for the HEADERS frame are:  <ins> The END_HEADERS bit indicates that this frame contains the entire payload necessary to provide a complete set of headers. </ins> The payload for a complete set of headers is provided by a  <ins> sequence of HEADERS frames, terminated by a HEADERS frame with the END_HEADERS flag set.  Once the sequence terminates, the payload of all HEADERS frames are concatenated and interpreted as a single </ins> block.  <ins> A HEADERS frame without the END_HEADERS flag set MUST be followed by a HEADERS frame for the same stream.  A receiver MUST treat the </ins> receipt of any other type of frame or a frame on a different stream as a ConnectionErrorHandler of type PROTOCOL_ERROR.
Original text:
window and the connection flow control window.  The sender MUST NOT send a flow controlled frame with a length that exceeds the space available in either of the flow control windows advertised by the <del> receiver.  Frames with zero length with the FINAL flag set (for </del>  example, an empty data frame) MAY be sent if there is no available space in either flow control window.

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
window and the connection flow control window.  The sender MUST NOT send a flow controlled frame with a length that exceeds the space available in either of the flow control windows advertised by the  <ins> receiver.  Frames with zero length with the END_STREAM flag set (for </ins> example, an empty data frame) MAY be sent if there is no available space in either flow control window.
Original text:
3.8.10.4. After a receiver reads in a frame that marks the end of a stream (for <del> example, a data stream with a FINAL flag set), it MUST cease </del>  transmission of WINDOW_UPDATE frames for that stream.  A sender is not obligated to maintain the available flow control window for streams that it is no longer sending on.

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
3.8.10.4. After a receiver reads in a frame that marks the end of a stream (for  <ins> example, a data stream with a END_STREAM flag set), it MUST cease </ins> transmission of WINDOW_UPDATE frames for that stream.  A sender is not obligated to maintain the available flow control window for streams that it is no longer sending on.
Original text:
4.2.2. The client initiates a request by sending a HEADERS+PRIORITY frame. <del> Requests that do not contain a body MUST set the FINAL flag, </del>  indicating that the client intends to send no further data on this stream, unless the server intends to push resources (see <del> PushResources).  HEADERS+PRIORITY frame does not contain the FINAL flag for requests that contain a body.  The body of a request follows as a series of DATA frames.  The last DATA frame sets the FINAL flag to indicate the end of the body. </del>  The header fields included in the HEADERS+PRIORITY frame contain all of the HTTP header fields associated with an HTTP request.  The

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
4.2.2. The client initiates a request by sending a HEADERS+PRIORITY frame.  <ins> Requests that do not contain a body MUST set the END_STREAM flag, </ins> indicating that the client intends to send no further data on this stream, unless the server intends to push resources (see  <ins> PushResources).  HEADERS+PRIORITY frame does not contain the END_STREAM flag for requests that contain a body.  The body of a request follows as a series of DATA frames.  The last DATA frame sets the END_STREAM flag to indicate the end of the body. </ins> The header fields included in the HEADERS+PRIORITY frame contain all of the HTTP header fields associated with an HTTP request.  The
Original text:
The server responds to a client request using the same stream identifier that was used by the request.  An HTTP response begins with a HEADERS frame.  An HTTP response body consists of a series of <del> DATA frames.  The last data frame contains a FINAL flag to indicate the end of the response.  A response that contains no body (such as a 204 or 304 response) consists only of a HEADERS frame that contains the FINAL flag to indicate no further data will be sent on the stream. </del>  The response status line is unfolded into name-value pairs like other HTTP header fields and must be present:

Reviewer comments:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Revised text:
The server responds to a client request using the same stream identifier that was used by the request.  An HTTP response begins with a HEADERS frame.  An HTTP response body consists of a series of  <ins> DATA frames.  The last data frame contains a END_STREAM flag to indicate the end of the response.  A response that contains no body (such as a 204 or 304 response) consists only of a HEADERS frame that contains the END_STREAM flag to indicate no further data will be sent on the stream. </ins> The response status line is unfolded into name-value pairs like other HTTP header fields and must be present:
Original text:
An 8-bit field reserved for frame-type specific boolean flags. <del> The least significant bit (0x1) - the END_STREAM bit - is defined for all frame types as an indication that this frame is the last the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Implementations MUST process the END_STREAM bit for all frames whose stream identifier field is not 0x0.  The END_STREAM bit MUST NOT be set on frames that use a stream identifier of 0. The remaining flags can be assigned semantics specific to the indicated frame type.  Flags that have no defined semantics for a particular frame type MUST be ignored, and MUST be left unset (0) when sending. </del>  A reserved 1-bit field.  The semantics of this bit are undefined and the bit MUST remain unset (0) when sending and MUST be ignored

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:
An 8-bit field reserved for frame-type specific boolean flags.  <ins> Flags are assigned semantics specific to the indicated frame type. Flags that have no defined semantics for a particular frame type MUST be ignored, and MUST be left unset (0) when sending. </ins> A reserved 1-bit field.  The semantics of this bit are undefined and the bit MUST remain unset (0) when sending and MUST be ignored