jiebi/TextFlow huggingface dataset:
Original text:
connection SHOULD still send a GOAWAY frame before terminating the connection.  The GOAWAY frame does not define any flags. The GOAWAY frame applies to the connection, not a specific stream.

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
connection SHOULD still send a GOAWAY frame before terminating the connection. <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer. </ins> The GOAWAY frame does not define any flags. The GOAWAY frame applies to the connection, not a specific stream.
Original text:
respond with a StreamErrorHandler or ConnectionErrorHandler of type FLOW_CONTROL_ERROR if it is unable to accept a frame. <del> The frame payload of a WINDOW_UPDATE frame is one reserved bit plus an unsigned 31-bit integer indicating the number of octets that the sender can transmit in addition to the existing flow-control window. The legal range for the increment to the flow-control window is 1 to 2 </del>  -1 (2,147,483,647) octets.

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
respond with a StreamErrorHandler or ConnectionErrorHandler of type FLOW_CONTROL_ERROR if it is unable to accept a frame.  <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The frame payload of a WINDOW_UPDATE frame is one reserved bit plus an unsigned 31-bit integer indicating the number of octets that the sender can transmit in addition to the existing flow-control window.  The legal range for the increment to the flow-control window is 1 to 2 </ins> -1 (2,147,483,647) octets.
Original text:
as the preceding frame is on the same stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without the END_HEADERS flag set. <del> The CONTINUATION frame payload contains a FieldBlock. </del>  The CONTINUATION frame defines the following flag:

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
as the preceding frame is on the same stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without the END_HEADERS flag set.  <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The CONTINUATION frame payload contains a FieldBlock. </ins> The CONTINUATION frame defines the following flag:
Original text:
Field names are strings of ASCII characters that are compared in a case-insensitive fashion.  Field names MUST be converted to lowercase <del> when constructing a HTTP/2 message.  A request or response containing an uppercase character ('A' to 'Z', ASCII 0x41 to 0x5a) in a field name MUST be treated as malformed. </del>  HPACK is capable of carrying field names or values that are not valid in HTTP.  Though HPACK can carry any octet, fields are not valid in

Reviewer comments:
The validation for uppercase characters is no longer listed separately, but instead included with the minimal validation.
NAME : factored out non controversial changes from

Revised text:
Field names are strings of ASCII characters that are compared in a case-insensitive fashion.  Field names MUST be converted to lowercase  <ins> when constructing a HTTP/2 message. </ins> HPACK is capable of carrying field names or values that are not valid in HTTP.  Though HPACK can carry any octet, fields are not valid in
Original text:
MUST NOT forward fields that contain any of the values that are listed as prohibited above. <del> Field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed except as defined by the processing rules for the field. </del>  8.1.2.1.

Reviewer comments:
See as an alternative.
Thanks everyone for your patience here. It's good to see this work out :)
Validating fields for characters has raised a concern where we don't have a clear delineation between framing and semantics. So the way that endpoints handle those cases is unclear. For requests in particular, the choice between resetting a stream and sending a 4xx response is unclear. It would be good if we could have more consistent overall behaviour here, but we have seen from the character composition issue (see ) that different implementations will enforce the rules at different layers. We probably need to allow for some flexibility. NAME has volunteered to help us navigate this somewhat nuanced issue.
I think this is reasonable. LGTM

Revised text:
MUST NOT forward fields that contain any of the values that are listed as prohibited above.  <ins> A recipient MAY treat a message that contains a field name or value that includes other characters disallowed by HTTP and HTTP as malformed. When a request message violates one of the requirements above, it SHOULD be responded to using the 400 (Bad Request) status code HTTP before the stream is reset, unless a more suitable status code is defined, or the status code cannot be sent (e.g., because the error occurs in a trailer field). Note that field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed; the requirements above only apply to the generic syntax for field values as defined in HTTP. </ins> 8.1.2.1.
Original text:
A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the <del> absence of mandatory fields or pseudo-header fields, or the inclusion of uppercase field names. </del>  A request or response that includes message content can include a

Reviewer comments:
See as an alternative.
Thanks everyone for your patience here. It's good to see this work out :)
Validating fields for characters has raised a concern where we don't have a clear delineation between framing and semantics. So the way that endpoints handle those cases is unclear. For requests in particular, the choice between resetting a stream and sending a 4xx response is unclear. It would be good if we could have more consistent overall behaviour here, but we have seen from the character composition issue (see ) that different implementations will enforce the rules at different layers. We probably need to allow for some flexibility. NAME has volunteered to help us navigate this somewhat nuanced issue.
I think this is reasonable. LGTM

Revised text:
A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the  <ins> absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). </ins> A request or response that includes message content can include a
Original text:
error codes.  These new registries appear in the new "Hypertext Transfer Protocol version 2 (HTTP/2)" section. <del> This document registers the </del>  <del> header field for use in HTTP. </del>  This document registers the

Reviewer comments:
new registry for fields; see
NAME removed upgrade and changed the registration of this header field to: Is that OK? Or would you prefer a complete registration update, as in: Field Name: HTTP2-Settings Status: Standard Ref.: Section 11.5 of RFC 7540 Comments: This field is obsoleted (this document).
That should be fine.

Revised text:
error codes.  These new registries appear in the new "Hypertext Transfer Protocol version 2 (HTTP/2)" section.  <ins> This revision of the document marks the </ins>  <ins> header field registered in RFC7540 obsolete. </ins> This document registers the
Original text:
This section marks the <del> header field registered in RFC7540 as obsoleted. </del>  11.6.

Reviewer comments:
new registry for fields; see
NAME removed upgrade and changed the registration of this header field to: Is that OK? Or would you prefer a complete registration update, as in: Field Name: HTTP2-Settings Status: Standard Ref.: Section 11.5 of RFC 7540 Comments: This field is obsoleted (this document).
That should be fine.

Revised text:
This section marks the  <ins> header field registered in RFC7540 as obsoleted.  The registration is updated to include the details as required by HTTP: </ins> 11.6.
Original text:
8. <del> HTTP/2 defines a framing of the HTTP message abstraction (HTTP). </del> 8.1.  A client sends an HTTP request on a new stream, using a previously unused StreamIdentifiers.  A server sends an HTTP response on the same stream as the request.

Reviewer comments:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Revised text:
8.  8.1. <ins> HTTP/2 defines a framing of the HTTP message abstraction (HTTP). </ins> A client sends an HTTP request on a new stream, using a previously unused StreamIdentifiers.  A server sends an HTTP response on the same stream as the request.
Original text:
connection-specific header fields as discussed in HTTP, or their messages will be treated by other HTTP/2 endpoints as malformed. <del> 8.1.2.3. The following pseudo-header fields are defined for HTTP/2 requests: All HTTP/2 requests MUST include exactly one valid value for the , , and pseudo-header fields, unless it is a CONNECT.  An HTTP request that omits mandatory pseudo-header fields is malformed. Individual HTTP/2 requests do not carry an explicit indicator of protocol version.  All HTTP/2 messages implicitly have a protocol version of "2.0" (see HTTP). 8.1.2.4. For HTTP/2 responses, a single pseudo-header field is defined that carries the HTTP status code field (see HTTP).  This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed. HTTP/2 responses implicitly have a protocol version of "2.0". 8.1.2.5. </del>  The COOKIE uses a semi-colon (";") to delimit cookie-pairs (or "crumbs").  This header field contains multiple values, but does not

Reviewer comments:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Revised text:
connection-specific header fields as discussed in HTTP, or their messages will be treated by other HTTP/2 endpoints as malformed.  <ins> 8.2.3. </ins> The COOKIE uses a semi-colon (";") to delimit cookie-pairs (or "crumbs").  This header field contains multiple values, but does not
Original text:
PROTOCOL_ERROR.  A server cannot set the SETTINGS_ENABLE_PUSH setting to a value other than 0 (see SettingValues). <del> 8.2.1. </del>  Server push is semantically equivalent to a server responding to a request; however, in this case, that request is also sent by the

Reviewer comments:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Revised text:
PROTOCOL_ERROR.  A server cannot set the SETTINGS_ENABLE_PUSH setting to a value other than 0 (see SettingValues).  <ins> 8.4.1. </ins> Server push is semantically equivalent to a server responding to a request; however, in this case, that request is also sent by the
Original text:
into the "reserved (local)" state for the server and the "reserved (remote)" state for the client. <del> 8.2.2. </del>  After sending the PUSH_PROMISE frame, the server can begin delivering the pushed response as a HttpResponse on a server-initiated stream

Reviewer comments:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Revised text:
into the "reserved (local)" state for the server and the "reserved (remote)" state for the client.  <ins> 8.4.2. </ins> After sending the PUSH_PROMISE frame, the server can begin delivering the pushed response as a HttpResponse on a server-initiated stream
Original text:
and ends with a frame bearing END_STREAM, which places the stream in the "closed" state. <del> 8.3. </del>  <del> In HTTP/1.x, the pseudo-method CONNECT (HTTP) is used to convert an HTTP connection into a tunnel to a remote host.  CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with </del>  resources. <del> In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes.  A CONNECT header section is constructed as defined in HttpRequest ("HttpRequest"), with a few differences.  Specifically: </del>  A CONNECT request that does not conform to these restrictions is malformed.

Reviewer comments:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Revised text:
and ends with a frame bearing END_STREAM, which places the stream in the "closed" state.  <ins> 8.5. </ins>  <ins> The CONNECT method (HTTP) is used to convert an HTTP connection into a tunnel to a remote host.  CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with </ins> resources.  <ins> In HTTP/2, the CONNECT method establishes a tunnel over a single HTTP/2 stream to a remote host, rather than converting the entire connection to a tunnel.  A CONNECT header section is constructed as defined in HttpRequest ("HttpRequest"), with a few differences. Specifically: </ins> A CONNECT request that does not conform to these restrictions is malformed.
Original text:
Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie- Hellman (DHE) TLS13 and 224 bits for cipher suites that use ephemeral <del> elliptic curve Diffie-Hellman (ECDHE) RFC4492.  Clients MUST accept </del>  DHE sizes of up to 4096 bits.  Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a ConnectionErrorHandler of type INADEQUATE_SECURITY.

Reviewer comments:
RFC 4492 is obsolete. This is a TLS 1.2 section, so it is OK to refer to the TLS 1.2 document here.

Revised text:
Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie- Hellman (DHE) TLS13 and 224 bits for cipher suites that use ephemeral  <ins> elliptic curve Diffie-Hellman (ECDHE) RFC8422.  Clients MUST accept </ins> DHE sizes of up to 4096 bits.  Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a ConnectionErrorHandler of type INADEQUATE_SECURITY.