jiebi/TextFlow huggingface dataset:
Original text:
that has not been sent and received.  When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending <del> a complete response (i.e., a frame with the END_STREAM flag). </del>  Clients MUST NOT discard responses as a result of receiving such a RST_STREAM, though clients can always discard responses at their discretion for other reasons.

Reviewer comments:
Going to let NAME have a look at this as well.
(Warning, I may have reached peak pedantry.) In Section 5.1, there are two references to frames which "contain" an ENDSTREAM flag. All HEADERS, CONTINUATION, and DATA frames contain this flag, which might be set or not. Most other references in the document are to the flag being set, which is more precise. There are also two references to frames "bearing" ENDSTREAM, which could be taken either way.
If you care enough to write the issue, maybe you also care enough to offer a pull request.

Revised text:
that has not been sent and received.  When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending  <ins> a complete response (i.e., a frame with the END_STREAM flag set). </ins> Clients MUST NOT discard responses as a result of receiving such a RST_STREAM, though clients can always discard responses at their discretion for other reasons.
Original text:
The response for a PUSH_PROMISE stream begins with a HEADERS frame, which immediately puts the stream into the "half-closed (remote)" state for the server and "half-closed (local)" state for the client, <del> and ends with a frame bearing END_STREAM, which places the stream in the "closed" state. </del>  8.5.

Reviewer comments:
Going to let NAME have a look at this as well.
(Warning, I may have reached peak pedantry.) In Section 5.1, there are two references to frames which "contain" an ENDSTREAM flag. All HEADERS, CONTINUATION, and DATA frames contain this flag, which might be set or not. Most other references in the document are to the flag being set, which is more precise. There are also two references to frames "bearing" ENDSTREAM, which could be taken either way.
If you care enough to write the issue, maybe you also care enough to offer a pull request.

Revised text:
The response for a PUSH_PROMISE stream begins with a HEADERS frame, which immediately puts the stream into the "half-closed (remote)" state for the server and "half-closed (local)" state for the client,  <ins> and ends with a frame with the END_STREAM flag set, which places the stream in the "closed" state. </ins> 8.5.
Original text:
The TCP connection can be closed by either peer.  The END_STREAM flag on a DATA frame is treated as being equivalent to the TCP FIN bit.  A client is expected to send a DATA frame with the END_STREAM flag set <del> after receiving a frame bearing the END_STREAM flag.  A proxy that </del>  receives a DATA frame with the END_STREAM flag set sends the attached data with the FIN bit set on the last TCP segment.  A proxy that receives a TCP segment with the FIN bit set sends a DATA frame with

Reviewer comments:
Going to let NAME have a look at this as well.
(Warning, I may have reached peak pedantry.) In Section 5.1, there are two references to frames which "contain" an ENDSTREAM flag. All HEADERS, CONTINUATION, and DATA frames contain this flag, which might be set or not. Most other references in the document are to the flag being set, which is more precise. There are also two references to frames "bearing" ENDSTREAM, which could be taken either way.
If you care enough to write the issue, maybe you also care enough to offer a pull request.

Revised text:
The TCP connection can be closed by either peer.  The END_STREAM flag on a DATA frame is treated as being equivalent to the TCP FIN bit.  A client is expected to send a DATA frame with the END_STREAM flag set  <ins> after receiving a frame with the END_STREAM flag set.  A proxy that </ins> receives a DATA frame with the END_STREAM flag set sends the attached data with the FIN bit set on the last TCP segment.  A proxy that receives a TCP segment with the FIN bit set sends a DATA frame with
Original text:
FieldBlock. The total number of padding octets is determined by the value of the <del> Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </del>  6.3.

Reviewer comments:
by copying the text from DATA
says: I think the intended reading is that when the parser reaches the point that only the FBF and the Padding remain, the length of Padding is given by Pad Length and the fragment is the balance. If Pad Length exceeds the remaining length of the frame, it's an error. There is a less-likely reading also allowed by the current phrasing, that Pad Length can't be more than half the remaining bytes (else Padding would exceed the size of the field block fragment). That's very unlikely to be the intended reading, but we should be clear here. I'd suggest simply taking the note from the end of DATA and putting it here verbatim.
LGTM, will let NAME take a read as well.

Revised text:
FieldBlock. The total number of padding octets is determined by the value of the  <ins> Pad Length field.  If the length of the padding is the length of the frame payload or greater, the recipient MUST treat this as a ConnectionErrorHandler of type PROTOCOL_ERROR. </ins> 6.3.
Original text:
that is not currently in the "idle" state. The total number of padding octets is determined by the value of the <del> Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </del>  6.7.

Reviewer comments:
by copying the text from DATA
says: I think the intended reading is that when the parser reaches the point that only the FBF and the Padding remain, the length of Padding is given by Pad Length and the fragment is the balance. If Pad Length exceeds the remaining length of the frame, it's an error. There is a less-likely reading also allowed by the current phrasing, that Pad Length can't be more than half the remaining bytes (else Padding would exceed the size of the field block fragment). That's very unlikely to be the intended reading, but we should be clear here. I'd suggest simply taking the note from the end of DATA and putting it here verbatim.
LGTM, will let NAME take a read as well.

Revised text:
that is not currently in the "idle" state. The total number of padding octets is determined by the value of the  <ins> Pad Length field.  If the length of the padding is the length of the frame payload or greater, the recipient MUST treat this as a ConnectionErrorHandler of type PROTOCOL_ERROR. </ins> 6.7.
Original text:
3.1. <del> The protocol defined in this document has two identifiers. Negotiating "h2" or "h2c" implies the use of the transport, security, </del>  framing, and message semantics described in this document. 3.2.

Reviewer comments:
... or the analysis in the security considerations. We had to walk a more careful path when RFC 7540 was published, so we were careful to legitimize h2c. In the years since, things have changed and we can be more direct. This isn't a "don't use h2c", but more of a disclaimer as far as security goes.
Maybe a hangover from trying to tear up the photos of the "http" URI and upgrade dance. But this seems to read oddly. On one hand: on the other: I don't have a solid suggestion to improve things.
How about we just remove "h2c" from the latter statement.
OK, that isn't going to fly. I just tried it. Pulling that string is unwise. We agreed to keep "prior knowledge" in the document, and the "h2c" ALPN token is part of that. The "h2c" upgrade token has been removed already. (Too subtle? Probably.)

Revised text:
3.1.  <ins> The protocol defined in this document has two identifiers.  Creating a connection based on either implies the use of the transport, </ins> framing, and message semantics described in this document. 3.2.
Original text:
10.  10.1. HTTP/2 relies on the HTTP definition of authority for determining

Reviewer comments:
... or the analysis in the security considerations. We had to walk a more careful path when RFC 7540 was published, so we were careful to legitimize h2c. In the years since, things have changed and we can be more direct. This isn't a "don't use h2c", but more of a disclaimer as far as security goes.
Maybe a hangover from trying to tear up the photos of the "http" URI and upgrade dance. But this seems to read oddly. On one hand: on the other: I don't have a solid suggestion to improve things.
How about we just remove "h2c" from the latter statement.
OK, that isn't going to fly. I just tried it. Pulling that string is unwise. We agreed to keep "prior knowledge" in the document, and the "h2c" ALPN token is part of that. The "h2c" upgrade token has been removed already. (Too subtle? Probably.)

Revised text:
10. <ins> The use of TLS is necessary to provide many of the security properties of this protocol.  Many of the claims in this section do not hold unless TLS is used as described in TLSUsage. </ins> 10.1. HTTP/2 relies on the HTTP definition of authority for determining
Original text:
3.3. A client can learn that a particular server supports HTTP/2 by other <del> means.  For example, ALT-SVC describes a mechanism for advertising this capability. A client MUST send the ConnectionHeader and then MAY immediately send HTTP/2 frames to such a server; servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </del>  Likewise, the server MUST send a ConnectionHeader.

Reviewer comments:
As stated in , it's misleading and contradictory. Better to concentrate on configuration for this, as that is the common usage.
Section 3.3 says the following about cleartext HTTP/2: I had previously conceived of Alt-Svc as requiring a certificate and TLS, but that's not strictly true. RFC 7838 says that a client MUST have reasonable assurances, and a TLS cert is one way to do that. It also says that the connection must have equal or better security properties, which implies you can't go from TLS to non-TLS. This statement suggests that it's valid to offer on an http:// URI if your server can accept direct-to-H2 connections, but doesn't explicitly say so. Is that the intended reading here? But RFC 7838 says: Perhaps that doesn't apply, because the alternative is the same server on the same TCP port. Still, I feel like this waves at Alt-Svc for a use which is, at best, under-specified; at worst, not actually possible.

Revised text:
3.3. A client can learn that a particular server supports HTTP/2 by other  <ins> means.  For example, a client could be configured with knowledge that a server supports HTTP/2. A client that knows that a server supports HTTP/2 can establish a TCP connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </ins> Likewise, the server MUST send a ConnectionHeader.
Original text:
connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 <del> connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </del>  Likewise, the server MUST send a ConnectionHeader.

Reviewer comments:
This text wasn't actually changed in , but I noticed it while reviewing. This says that implementations which support TLS MUST use ALPN, but that's not really tied to what the implementation supports -- it's tied to what the current connection is doing. If you support TLS but are using cleartext TCP for the current connection (regardless of why), you're not required to use ALPN.

Revised text:
connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2  <ins> connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </ins> Likewise, the server MUST send a ConnectionHeader.
Original text:
HTTP/2 uses DATA frames to carry message content.  The <del> transfer encoding defined in HTTP11 cannot be used in HTTP/2. </del>  Trailer fields are carried in a field block that also terminates the stream.  That is, trailer fields comprise a sequence starting with a

Reviewer comments:
The original issue here was concerned with Transfer-Encoding, but this was not a normative statement, it was a note. With a forward reference, this is better. The section on connection-specific headers probably could have been more specific. Now that the -semantics draft has a specific list of things (plus whatever lists), we can lean on that more directly.
HTTP/2 prohibits Transfer-Encoding, but doesn't actually prohibit other values: HTTP/3 broadened this language to cover all transfer codings: Should H2bis follow suit?
Can you take this to the list Mike? It seems like the only sensible answer, but I'd like to double-check.
In my mind, I was relying on Section 8.2.2: However, that probably isn't linked well enough to the . Unfortunately, there isn't a term we can just lift out; perhaps something like this:
On review with full context, the text that Mike cites is fine. It's an informational note. Mark's note here about the linkage to -semantics is good though. I will float this on the list to see if I messed up (again).

Revised text:
HTTP/2 uses DATA frames to carry message content.  The  <ins> transfer encoding defined in HTTP11 cannot be used in HTTP/2; see ConnectionSpecific. </ins> Trailer fields are carried in a field block that also terminates the stream.  That is, trailer fields comprise a sequence starting with a
Original text:
header field (HTTP) to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/2 message containing <del> connection-specific header fields; any message containing connection- specific header fields MUST be treated as malformed. </del>  The only exception to this is the TE header field, which MAY be present in an HTTP/2 request; when it is, it MUST NOT contain any

Reviewer comments:
The original issue here was concerned with Transfer-Encoding, but this was not a normative statement, it was a note. With a forward reference, this is better. The section on connection-specific headers probably could have been more specific. Now that the -semantics draft has a specific list of things (plus whatever lists), we can lean on that more directly.
HTTP/2 prohibits Transfer-Encoding, but doesn't actually prohibit other values: HTTP/3 broadened this language to cover all transfer codings: Should H2bis follow suit?
Can you take this to the list Mike? It seems like the only sensible answer, but I'd like to double-check.
In my mind, I was relying on Section 8.2.2: However, that probably isn't linked well enough to the . Unfortunately, there isn't a term we can just lift out; perhaps something like this:
On review with full context, the text that Mike cites is fine. It's an informational note. Mark's note here about the linkage to -semantics is good though. I will float this on the list to see if I messed up (again).

Revised text:
header field (HTTP) to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/2 message containing  <ins> connection-specific header fields.  This includes the header field and those listed as having connection-specific semantics in HTTP (that is, , , , and ).  Any message containing connection-specific header fields MUST be treated as malformed. </ins> The only exception to this is the TE header field, which MAY be present in an HTTP/2 request; when it is, it MUST NOT contain any
Original text:
status code (HTTP). The semantics of 101 (Switching Protocols) aren't applicable to a <del> multiplexed protocol.  Alternative protocols are able to use the same </del>  mechanisms that HTTP/2 uses to negotiate their use (see starting). 8.7.

Reviewer comments:
I know that Cory beat me to it with , but I had written text. I only forgot to make the PR. Cory can decide which he likes better :)
In the aside about HTTP/2 deliberately not supporting Upgrade, it feels worth mentioning that we later partially reversed ourselves and brought back a moral equivalent of Upgrade with a less obvious name. Reference to RFC8441 appropriate here?
You put more things in your citation block, so it’s clearly better.

Revised text:
status code (HTTP). The semantics of 101 (Switching Protocols) aren't applicable to a  <ins> multiplexed protocol.  Similar functionality might be enabled through the use of RFC8441 and other protocols are able to use the same </ins> mechanisms that HTTP/2 uses to negotiate their use (see starting). 8.7.
Original text:
This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space.  The "HTTP/2 <del> Frame Type" registry operates under either of the RFC8126 or RFC8126 policies. </del>  New entries in this registry require the following information:

Reviewer comments:
The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.

Revised text:
This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space.  The "HTTP/2  <ins> Frame Type" registry operates under either of the "IETF Review" (RFC8126) or "IESG Approval" (RFC8126) policies. </ins> New entries in this registry require the following information:
Original text:
This document establishes a registry for HTTP/2 settings.  The "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2 <del> Settings" registry operates under the RFC8126. </del>  New registrations are advised to provide the following information:

Reviewer comments:
Followup for .
The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.

Revised text:
This document establishes a registry for HTTP/2 settings.  The "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2  <ins> Settings" registry operates under the "Expert Review" policy (RFC8126). </ins> New registrations are advised to provide the following information:
Original text:
This document establishes a registry for HTTP/2 error codes.  The "HTTP/2 Error Code" registry manages a 32-bit space.  The "HTTP/2 <del> Error Code" registry operates under the RFC8126. </del>  Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new

Reviewer comments:
Followup for .
The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.

Revised text:
This document establishes a registry for HTTP/2 error codes.  The "HTTP/2 Error Code" registry manages a 32-bit space.  The "HTTP/2  <ins> Error Code" registry operates under the "Expert Review" policy (RFC8126). </ins> Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new
Original text:
PUSH_PROMISE frames. The body of a PUSH_PROMISE includes a "Promised-Stream-ID".  This <del> unsigned 31-bit integer indentifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see </del>  StreamCreation). PUSH_PROMISE frames MUST be associated with an existing stream.  If

Reviewer comments:
Fix some typos
"overridden" is the correct spelling; can you remove those changes? Thanks.
NAME it was "overriden", I changed it to "overridden". Am I missing something here?
No, I just need to slow down when I read diffs :) Thanks!
:smile:

Revised text:
PUSH_PROMISE frames. The body of a PUSH_PROMISE includes a "Promised-Stream-ID".  This  <ins> unsigned 31-bit integer identifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see </ins> StreamCreation). PUSH_PROMISE frames MUST be associated with an existing stream.  If
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> receipient MUST respond with a StreamErrorHandler of type </del>  PROTOCOL_ERROR. The HEADERS frame changes the connection state as defined in

Reviewer comments:
Fix some typos
"overridden" is the correct spelling; can you remove those changes? Thanks.
NAME it was "overriden", I changed it to "overridden". Am I missing something here?
No, I just need to slow down when I read diffs :) Thanks!
:smile:

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 StreamErrorHandler of type </ins> PROTOCOL_ERROR. The HEADERS frame changes the connection state as defined in
Original text:
HTTP fields (HTTP) are conveyed by HTTP/2 in the HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with COMPRESSION. <del> To improve efficiency and interoperability, field names MUST be converted to lowercase when constructing an HTTP/2 message. </del>  8.2.1.

Reviewer comments:
Just state it. No need to justify it so (especially as this invites questions about the claimed benefits). This is less than Julian wanted from , but I think that it is important to include a requirement like this very clearly and it isn't really said anywhere else. At least not directly.
converted to lowercase when constructing an HTTP/2 message. I think this is somewhat misleading, it just provides the motivation why the lowercase format was introduced initially. I would just remove the sentence and potentially insert a note about lower-casing into the field name validity statements.
Agreed, I don't think the spec needs to defend itself on this choice.

Revised text:
HTTP fields (HTTP) are conveyed by HTTP/2 in the HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with COMPRESSION.  <ins> Field names MUST be converted to lowercase when constructing an HTTP/2 message. </ins> 8.2.1.