jiebi/TextFlow huggingface dataset:
Original text:
unordered set of references to entries in the header table.  This is used for the differential encoding of a new header set. <del> A header set is a potentially ordered group of header fields that are encoded jointly.  A complete set of key-value pairs contained in a HTTP request or response is a header set. </del>  A header field can be represented in encoded form either as a literal or as an index (see header.representation).

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

Revised text:
unordered set of references to entries in the header table.  This is used for the differential encoding of a new header set.  <ins> A header set is an unordered group of header fields that are encoded jointly.  A complete set of key-value pairs contained in a HTTP request or response is a header set. </ins> A header field can be represented in encoded form either as a literal or as an index (see header.representation).
Original text:
When decoding a set of header field representations, some operations emit a header field (see header.emission).  Emitted <del> header fields can be safely passed to the upper processing layers as part of the current Header Set. </del>  3.1.1.

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

Revised text:
When decoding a set of header field representations, some operations emit a header field (see header.emission).  Emitted  <ins> header fields are added to the current header set and cannot be removed. </ins> 3.1.1.
Original text:
a header table and a reference set.  Everything else is either immutable or conceptual. <del> Using HTTP, messages are exchanged between a client and a server in both direction.  To keep the encoding of header fields in each direction independent from the other direction, there is one encoding context for each direction. The header fields contained in a PUSH_PROMISE frame sent by a server to a client are encoded within the same context as the header fields contained in the HEADERS frame corresponding to a response sent from the server to the client. </del>  3.1.2.

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

Revised text:
a header table and a reference set.  Everything else is either immutable or conceptual.  <ins> HTTP messages are exchanged between a client and a server in both directions.  The encoding of header fields in each direction is independent from the other direction.  There is a single encoding context for each direction used to encode all header fields sent in that direction. </ins> 3.1.2.
Original text:
The encoder decides how to update the header table and as such can control how much memory is used by the header table.  To limit the <del> memory requirements on the decoder side, the header table size is strictly bounded (see maximum.table.size). </del>  The header table is updated during the processing of a set of header field representations (see header.representation.processing).

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

Revised text:
The encoder decides how to update the header table and as such can control how much memory is used by the header table.  To limit the  <ins> memory requirements of the decoder, the header table size is strictly bounded (see maximum.table.size). </ins> The header table is updated during the processing of a set of header field representations (see header.representation.processing).
Original text:
endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates. <del> Bit 2 is reserved for future use. </del>  Bit 3 being set indicates that the Pad Low field is present.

Reviewer comments:
NAME did you just forget to create the pull request?
Didn't realize you couldn't merge from the referenced issue. What do you need from me to merge the commit?
Just some indication that you think that this is ready, that's all.
Do you think we need to add a requirement for must emit? or is the not coalesce sufficient?
Now that you mention it, MUST preserve is really what we are going for.
added "MUST preserve"
There is some usefulness from both an extensibility perspective and a load balancing perspective to indicate multiple messages over an individual stream. This issue is to un-reserve the 0x02 END_MESSAGE flag to ensure that intermediaries that are deployed proxy the flag so that they are agnostic to the layered protocol and can still successfully load balance messages appropriately.
Note that this places a requirement on proxies that they cannot coalesce data frames across "END_MESSAGE" boundaries.
Discussed in Zurich with no real conclusion. Support and opposition were weak.
Discussed in Zurich; accepted in principle. Jeff to do a pull request.
Renamed ENDMESSAGE to ENDSEGMENT to avoid any confusion with HTTP messages. Feel free to re-name. Couldn't find any text that stated intermediaries could combine frames but may want to add a requirement that intermediaries must re-emit the flag at the same byte position.

Revised text:
endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates.  <ins> Bit 2 being set indicates that this frame is the last for the current segment.  Intermediaries MUST NOT coalesce frames across a segment boundary and MUST preserve segment boundaries when forwarding frames. </ins> Bit 3 being set indicates that the Pad Low field is present.
Original text:
Implementations MUST support all of the settings defined by this specification and MAY support additional settings defined by <del> extensions.  Unsupported or unrecognized settings MUST be ignored. New settings MUST NOT be defined or implemented in a way that requires endpoints to understand them in order to communicate successfully. </del>  Each setting in a SETTINGS frame replaces the existing value for that setting.  Settings are processed in the order in which they appear,

Reviewer comments:
This is a really minor thing, but as I was reading the spec, I was wondering for a bit what "extensions" meant (user defined? something else?). I think the intent is to reference extensions defined by future RFCs that revise HTTP/2 protocol.

Revised text:
Implementations MUST support all of the settings defined by this specification and MAY support additional settings defined by  <ins> extensions to this protocol.  Unsupported or unrecognized settings MUST be ignored.  New settings MUST NOT be defined or implemented in a way that requires endpoints to understand them in order to communicate successfully. </ins> Each setting in a SETTINGS frame replaces the existing value for that setting.  Settings are processed in the order in which they appear,
Original text:
The HEADERS frame payload has the following fields:  A single reserved bit.  This field is optional and is only present if the PRIORITY flag is set.

Reviewer comments:
Padding is made to a frame and other frames (DATA and CONTINUATION) have these 2 bytes right after the frame header. It is easier for implementation to put the same constructs in the same position.

Revised text:
The HEADERS frame payload has the following fields: <ins> Padding size high bits.  This field is only present if the PAD_HIGH flag is set. Padding size low bits.  This field is only present if the PAD_LOW flag is set. </ins> A single reserved bit.  This field is optional and is only present if the PRIORITY flag is set.
Original text:
This field is optional and is only present if the PRIORITY flag is set. <del> Padding size high bits.  This field is only present if the PAD_HIGH flag is set. Padding size low bits.  This field is only present if the PAD_LOW flag is set. </del> A HeaderBlock. Padding octets.

Reviewer comments:
Padding is made to a frame and other frames (DATA and CONTINUATION) have these 2 bytes right after the frame header. It is easier for implementation to put the same constructs in the same position.

Revised text:
This field is optional and is only present if the PRIORITY flag is set.  A HeaderBlock. Padding octets.
Original text:
or <del> frame, with the END_HEADERS or END_PUSH_PROMISE flag set, or </del>  a or <del> frame with the END_HEADERS or END_PUSH_PROMISE flag cleared and one or more </del>  frames, where the last

Reviewer comments:
This simplifies the text and makes flag consistent with CONTINUATION which only bears ENDHEADERS. Technically, both have the same meaning of ending sequence of header block fragments. Therefore there is no reason to use the different flag name for the same purpose. This will also make the implementaion easier because most likely HEADERS and PUSHPROMISE handling share the same code and dancing with ENDPUSHPROMISE and END_HEADERS is not fun. Although currently they have the same number, it is not guaranteed to the last. If they are guarenteed to be the same, then it is simpler to use the same name for same value.

Revised text:
or  <ins> frame, with the END_HEADERS flag set, or </ins> a or  <ins> frame with the END_HEADERS flag cleared and one or more </ins> frames, where the last
Original text:
or <del> frames MUST have the END_PUSH_PROMISE or END_HEADERS flag set (respectively). </del>  Header block fragments can only be sent as the payload of

Reviewer comments:
This simplifies the text and makes flag consistent with CONTINUATION which only bears ENDHEADERS. Technically, both have the same meaning of ending sequence of header block fragments. Therefore there is no reason to use the different flag name for the same purpose. This will also make the implementaion easier because most likely HEADERS and PUSHPROMISE handling share the same code and dancing with ENDPUSHPROMISE and END_HEADERS is not fun. Although currently they have the same number, it is not guaranteed to the last. If they are guarenteed to be the same, then it is simpler to use the same name for same value.

Revised text:
or  <ins> frames MUST have the END_HEADERS flag set. </ins> Header block fragments can only be sent as the payload of
Original text:
, <del> or CONTINUATION without the END_HEADERS or END_PUSH_PROMISE flag set. </del>  The CONTINUATION frame payload has the following fields:

Reviewer comments:
This simplifies the text and makes flag consistent with CONTINUATION which only bears ENDHEADERS. Technically, both have the same meaning of ending sequence of header block fragments. Therefore there is no reason to use the different flag name for the same purpose. This will also make the implementaion easier because most likely HEADERS and PUSHPROMISE handling share the same code and dancing with ENDPUSHPROMISE and END_HEADERS is not fun. Although currently they have the same number, it is not guaranteed to the last. If they are guarenteed to be the same, then it is simpler to use the same name for same value.

Revised text:
,  <ins> or CONTINUATION without the END_HEADERS flag set. </ins> The CONTINUATION frame payload has the following fields:
Original text:
The HTTP/2 specification is split into four parts: <del> starting covers how a HTTP/2 connection is initiated. </del>  The FramingLayer and StreamsLayer layers describe the way HTTP/2 frames are structured and formed into multiplexed streams.

Reviewer comments:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Revised text:
The HTTP/2 specification is split into four parts:  <ins> starting covers how an HTTP/2 connection is initiated. </ins> The FramingLayer and StreamsLayer layers describe the way HTTP/2 frames are structured and formed into multiplexed streams.
Original text:
6.9.2. <del> When a HTTP/2 connection is first established, new streams are </del>  created with an initial flow control window size of 65,535 bytes. The connection flow control window is 65,535 bytes.  Both endpoints can adjust the initial window size for new streams by including a

Reviewer comments:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Revised text:
6.9.2.  <ins> When an HTTP/2 connection is first established, new streams are </ins> created with an initial flow control window size of 65,535 bytes. The connection flow control window is 65,535 bytes.  Both endpoints can adjust the initial window size for new streams by including a
Original text:
conveyed by other means.  As such, a HTTP/2 message containing Connection MUST be treated as malformed. <del> This means that an intermediary transforming a HTTP/1.x message to </del>  HTTP/2 will need to remove any header fields nominated by the Connection header field, along with the Connection header field itself.  Such intermediaries SHOULD also remove other connection-

Reviewer comments:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Revised text:
conveyed by other means.  As such, a HTTP/2 message containing Connection MUST be treated as malformed.  <ins> This means that an intermediary transforming an HTTP/1.x message to </ins> HTTP/2 will need to remove any header fields nominated by the Connection header field, along with the Connection header field itself.  Such intermediaries SHOULD also remove other connection-
Original text:
Connection. One exception to this is the TE header field, which MAY be present in <del> a HTTP/2 request, but when it is MUST NOT contain any value other </del>  than "trailers". HTTP/2 purposefully does not support upgrade to another protocol.

Reviewer comments:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Revised text:
Connection. One exception to this is the TE header field, which MAY be present in  <ins> an HTTP/2 request, but when it is MUST NOT contain any value other </ins> than "trailers". HTTP/2 purposefully does not support upgrade to another protocol.
Original text:
Clients receiving a pushed response MUST validate that the server is authorized to push it using the same-origin policy (RFC6454).  For <del> example, a HTTP/2 connection to "example.com" is generally </del>  "www.example.org". 8.3.

Reviewer comments:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Revised text:
Clients receiving a pushed response MUST validate that the server is authorized to push it using the same-origin policy (RFC6454).  For  <ins> example, an HTTP/2 connection to "example.com" is generally </ins> "www.example.org". 8.3.
Original text:
Due to implementation limitations, it might not be possible to fail TLS negotiation based on all of these requirements.  An endpoint MUST <del> terminate a HTTP/2 connection that is opened on a TLS session that </del>  does not meet these minimum requirements with a ConnectionErrorHandler of type

Reviewer comments:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Revised text:
Due to implementation limitations, it might not be possible to fail TLS negotiation based on all of these requirements.  An endpoint MUST  <ins> terminate an HTTP/2 connection that is opened on a TLS session that </ins> does not meet these minimum requirements with a ConnectionErrorHandler of type
Original text:
The PUSH_PROMISE frame defines the following flags: PUSH_PROMISE frames MUST be associated with an existing, peer- <del> initiated stream.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </del>  .

Reviewer comments:
I realize this is somewhat redundant given section 5.1.1, so I don't mind if this pull is rejected. The main reason I think this might be useful is since there are two different stream identifiers involved in PUSHPROMISE: the promised stream id and the stream identifier in the common header. The extra sentence just makes it explicit how PUSHPROMISE is linked to an earlier request. It also puts the following sentence in better context.

Revised text:
The PUSH_PROMISE frame defines the following flags: PUSH_PROMISE frames MUST be associated with an existing, peer-  <ins> initiated stream.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </ins> .
Original text:
segment boundary and MUST preserve segment boundaries when forwarding frames. <del> Bit 5 being set indicates that the Pad Low field is present. </del>  <del> Bit 6 being set indicates that the Pad High field is present. </del>  This bit MUST NOT be set unless the PAD_LOW flag is also set. Endpoints that receive a frame with PAD_HIGH set and PAD_LOW cleared MUST treat this as a ConnectionErrorHandler of type

Reviewer comments:
I believe that PADLOW and PADHIGH bits in DATA frame were not updated when the dependency based priority was merged. It is quite a headache for implementors if these bits differ across frames.
Yeah, my bad. I missed one.

Revised text:
segment boundary and MUST preserve segment boundaries when forwarding frames.  <ins> Bit 4 being set indicates that the Pad Low field is present. </ins>  <ins> Bit 5 being set indicates that the Pad High field is present. </ins> This bit MUST NOT be set unless the PAD_LOW flag is also set. Endpoints that receive a frame with PAD_HIGH set and PAD_LOW cleared MUST treat this as a ConnectionErrorHandler of type
Original text:
setting of the peer endpoint is set to 0. <del> The HEADERS frame payload has the following fields: </del>  Padding size high bits.  This field is only present if the PAD_HIGH flag is set.

Reviewer comments:
I believe that PADLOW and PADHIGH bits in DATA frame were not updated when the dependency based priority was merged. It is quite a headache for implementors if these bits differ across frames.
Yeah, my bad. I missed one.

Revised text:
setting of the peer endpoint is set to 0.  <ins> The PUSH_PROMISE frame payload has the following fields: </ins> Padding size high bits.  This field is only present if the PAD_HIGH flag is set.
Original text:
requests can be highly redundant, so compression can reduce the size of requests and responses significantly.  2.1. The HTTP/2 specification is split into four parts:

Reviewer comments:
HTTP/2 has different properties to HTTP/1 regarding server-side load, because load balancers etc. currently exploit HTTP/1's short connections. HTTP/2 has much longer-lived connections, making it more difficult to load balance traffic. A mechanism to direct the client to use a different server/port would mitigate this. While GOAWAY could be used to do this, it introduces latency as the new connection is set up.
Alt-Svc?
URL
NAME is this really in the next milestone? It doesn't seem like we're ready yet.
Should get out a draft momentarily; if we don't make it, that's fine, but if we can, it'd be good to have a bit of discussion first.
NAME this missed the boat. Can I request that you put together something we can discuss in London instead.
Yes, it's on the list for discussion there. The boat technically is delayed at dock...
Discussed in London; agreed to using ALTSVC frame for this.

Revised text:
requests can be highly redundant, so compression can reduce the size of requests and responses significantly. <ins> HTTP/2 also supports HTTP Alternative Services (see AltSvc) using the alt-frame, to allow servers more control over traffic to them. </ins> 2.1. The HTTP/2 specification is split into four parts:
Original text:
flag is set. An 8-bit weight for the identified priority group, see <del> StreamPriority.  This field is optional and is only present if the </del>  PRIORITY_GROUP flag is set. A single bit flag indicates that the stream dependency is

Reviewer comments:
This wording once existed in priority branch in github, but missing in the current draft.

Revised text:
flag is set. An 8-bit weight for the identified priority group, see  <ins> StreamPriority.  Add one to the value to obtain a weight between 1 and 256.  This field is optional and is only present if the </ins> PRIORITY_GROUP flag is set. A single bit flag indicates that the stream dependency is
Original text:
.  DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a ConnectionErrorHandler of type

Reviewer comments:
A proposal for adding GZIP compression to DATA frames. One possible resolution for .
This looks good. Thanks for putting this together. We'll see how the discussion progresses.
I realise we might also want to modify Section 8.1.3.5 Malformed Messages, to explain that Content-Length either cannot be sent if any frame is compressed, or measures the length after inflation, depending on how closely this maps to transfer encoding (URL). I suppose that's a follow-up issue for the WG to discuss.
No. You are right. Content-length applies pre-compression or post-decompression. We need to that clear. On Apr 22, 2014 4:28 PM, "Matthew Kerwin" EMAIL wrote:

Revised text:
. <ins> Bit 6 being set indicates that the data in the frame has been compressed with GZIP compression (RFC1952).  The compression only applies to the frame in which it is signalled, and no compression state is carried over from frame to frame.  An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set unless it receives a parameter set to a value of 1.  An endpoint that has not both set this parameter to 1 and had it acknowledged MUST treat the receipt of a DATA frame with the COMPRESSED flag set as a ConnectionErrorHandler of type . </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a ConnectionErrorHandler of type
Original text:
.  10.6. HTTP/2 enables greater use of compression for both header fields

Reviewer comments:
A proposed explanation for what to do with large header blocks.
Discussed in NYC; this can be considered editorial.

Revised text:
. <ins> 10.5.1. A large HeaderBlock can cause an implementation to commit a large amount of state.  In servers and intermediaries, header fields that are critical to routing, such as ":authority", ":path", and ":scheme" are not guaranteed to be present early in the header block.  In particular, values that are in the reference set cannot be emitted until the header block ends. This can prevent streaming of the header fields to their ultimate destination, and forces the endpoint to buffer the entire header block.  Since there is no hard limit to the size of a header block, an endpoint could be forced to exhaust available memory. A server that receives a larger header block than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code RFC6585.  A client can discard responses that it cannot process. The header block MUST be processed to ensure a consistent connection state, unless the connection is closed. </ins> 10.6. HTTP/2 enables greater use of compression for both header fields
Original text:
6.3. The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can <del> be sent at any time for an existing stream.  This enables reprioritization of existing streams. </del>  The payload of a PRIORITY frame contains the following fields:

Reviewer comments:
... as new priority scheme demands and implies, but does not expressly permit. For .

Revised text:
6.3. The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can  <ins> be sent at any time for an existing stream, including closed streams. This enables reprioritization of existing streams. </ins> The payload of a PRIORITY frame contains the following fields: