jiebi/CodeConvo huggingface dataset:
Code change:
By removing the word negotiating and avoiding the actual identifiers, we can get the important point across
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.)

Related discussion:
text: 3.1. <del> The protocol defined in this document has two identifiers. Negotiating "h2" or "h2c" implies the use of the transport, security, framing, and message semantics described in this document. </del> <ins> The protocol defined in this document has two identifiers.  Creating a connection based on either implies the use of the transport, security, framing, and message semantics described in this document. </ins> 3.2.
Code change:
The old text stated padding things were identical to DATA frames. That might not be entirely true. So just spell out the requirements expicitly.
I just realised RFC 7540 was always this way, but it doesn't seem right to me. The DATA frame definition includes normative requirements on sender and receiver using the field. I presume the HEADERS frame is supposed the treat padding the same but it isn't written down. edit: plus PUSH_PROMISE
Ah, it's stated in a separate paragraph at the end of each frame definition section. That's annoying but I guess its fine.
Yeah, so the short answer there is that they behave differently in some ways (at least with respect to flow control). If you think there’s a better way to structure the section I think you’re welcome to take a crack at it.
I didn't actually make the leap to flow control, that makes me more inclined to avoid the cross reference to DATA frames. I made to just make everything explicit at the cost of a few more lines of text.

Related discussion:
text: The HEADERS frame changes the connection state as described in FieldBlock. <del> The HEADERS frame can include padding.  Padding fields and flags are identical to those defined for DATA.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </del> <ins> The total number of padding octets is determined by the value of the Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </ins> 6.3.
Code change:
The old text stated padding things were identical to DATA frames. That might not be entirely true. So just spell out the requirements expicitly.
I just realised RFC 7540 was always this way, but it doesn't seem right to me. The DATA frame definition includes normative requirements on sender and receiver using the field. I presume the HEADERS frame is supposed the treat padding the same but it isn't written down. edit: plus PUSH_PROMISE
Ah, it's stated in a separate paragraph at the end of each frame definition section. That's annoying but I guess its fine.
Yeah, so the short answer there is that they behave differently in some ways (at least with respect to flow control). If you think there’s a better way to structure the section I think you’re welcome to take a crack at it.
I didn't actually make the leap to flow control, that makes me more inclined to avoid the cross reference to DATA frames. I made to just make everything explicit at the cost of a few more lines of text.

Related discussion:
text: Note that an illegal stream identifier is an identifier for a stream that is not currently in the "idle" state. <del> The PUSH_PROMISE frame can include padding.  Padding fields and flags are identical to those defined for DATA. </del> <ins> The total number of padding octets is determined by the value of the Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </ins> 6.7.
Code change:
thanks both, good suggestions
... and HTTP/2's positives too! protocol. However, the way HTTP/1.1 uses the underlying transport ([RFC7230], Section 6) has several characteristics that have a negative overall effect on application performance today. a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency. I think time has shown these claims to not be great. How about cutting cruft and saying and then a tweak to a later paragraph in the intro to state that no one is perfect
It looks like you have a pull request that is dressed up as an issue :)
If you're receptive to change, I am willing to try and edit horrible XML
One change and I'm happy

Related discussion:
text: 1. <del> The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol.  However, the way HTTP/1.1 uses the underlying transport (HTTP11) has several characteristics that have a negative overall effect on application performance today. In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection.  HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking.  Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency. </del> <ins> The performance of applications using the Hypertext Transfer Protocol (HTTP) is linked to how each version of HTTP uses the underlying transport, and the conditions under which the transport operates. Making multiple concurrent requests can reduce latency and improve application performance.  HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection.  HTTP/1.1 (HTTP11) added request pipelining, but this only partially addressed request concurrency and still suffers from application-layer head-of-line blocking.  Therefore, HTTP/1.0 and HTTP/1.1 clients use multiple connections to a server to make concurrent requests. </ins> Furthermore, HTTP fields are often repetitive and verbose, causing unnecessary network traffic as well as causing the initial TCP TCP
Code change:
thanks both, good suggestions
... and HTTP/2's positives too! protocol. However, the way HTTP/1.1 uses the underlying transport ([RFC7230], Section 6) has several characteristics that have a negative overall effect on application performance today. a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency. I think time has shown these claims to not be great. How about cutting cruft and saying and then a tweak to a later paragraph in the intro to state that no one is perfect
It looks like you have a pull request that is dressed up as an issue :)
If you're receptive to change, I am willing to try and edit horrible XML
One change and I'm happy

Related discussion:
text: TCP connections can be used in comparison to HTTP/1.x.  This means less competition with other flows and longer-lived connections, which in turn lead to better utilization of available network capacity. <ins> Note, however, that TCP head-of-line blocking is not addressed by this protocol. </ins> Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing.
Code change:
At two points in the document, it refers to "previous versions of this document," which I take to mean RFC 7540, since we don't discuss differences from previous drafts when we publish the RFC. Is there a reason not to simply say "RFC 7540" in these places, similar to the discussion in 5.3?
Probably not.

Related discussion:
text: 11.7. <del> Previous versions of this document (RFC7540) registered an upgrade token.  This capability has been removed: see versioning. </del> <ins> RFC7540 registered an upgrade token.  This capability has been removed: see versioning. </ins>
Code change:
Which changes to
The new reference is to the frame type (not the settings themselves), so I might have preferred the original, but I don't mind. The section is about more than the frame anyway.

Related discussion:
text: does not affect the existing options for extending HTTP, such as defining new methods, status codes, or fields (see HTTP). <del> Extensions are permitted to use new FrameHeader, new SettingValues, or new ErrorCodes.  Registries are established for managing these extension points: iana-frames, iana-settings, and iana-errors. </del> <ins> Extensions are permitted to use new FrameHeader, new SETTINGS, or new ErrorCodes.  Registries are established for managing these extension points: iana-frames, iana-settings, and iana-errors. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames
Code change:
We could try to make every statement precise. We could add "of the frames defined in this document" to a bunch of places. Or we could make a (better) blanket statement. That is what this does.
As discussed in , the current language of 5.1 prohibits all frames on closed streams other than the ones indicated. It is not clear whether the requirement in Section 5.5 constitutes "more specific guidance." My suggestion in the erratum was to scope "any frame" to "any frame defined in this document" where we might allow an extension frame to appear, since that was the minimal change to the RFC 7540 text, but the editors might choose a broader rewording.
So the text already says: "Frames of unknown types are ignored." right next to the guidance you refer to. Maybe we just need to be more direct about this.
Be careful Martin, you removed the sentence "Frames of unknown types are ignored" so I think we're losing one piece of information when looking at the patch. I should re-read it withiin its context to make sure we don't miss anything, but I preferred to warn.
NAME yes, that was a deliberate change. I replaced that text with a complete paragraph and a reference to the extensibility section, which already covers the rules for unknown frames clearly: "Implementations MUST discard frames that have unknown or unsupported types."
I think this is fine.

Related discussion:
text: Streams have the following states: <del> In the absence of more specific guidance elsewhere in this document, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a ConnectionErrorHandler of type PROTOCOL_ERROR.  Note that PRIORITY can be sent and received in any stream state.  Frames of unknown types are ignored. </del> <ins> In the absence of more specific rules, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a ConnectionErrorHandler of type PROTOCOL_ERROR.  Note that PRIORITY can be sent and received in any stream state. The rules in this section only apply to frames defined in this document.  Receipt of frames for which the semantics are unknown cannot be treated as an error as the conditions for sending and receiving those frames are also unknown; see extensibility. </ins> An example of the state transitions for an HTTP request/response exchange can be found in HttpExamples.  An example of the state
Code change:
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.

Related discussion:
text: PROTOCOL_ERROR; errors on the connection flow-control window MUST be treated as a ConnectionErrorHandler. <del> WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the END_STREAM flag.  This means that a receiver could receive a </del> <ins> WINDOW_UPDATE can be sent by a peer that has sent a frame with the END_STREAM flag set.  This means that a receiver could receive a </ins> WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream. A receiver MUST NOT treat this as an error (see StreamStates).
Code change:
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.

Related discussion:
text: interim response consists of a HEADERS frames (which might be followed by zero or more CONTINUATION frames) containing the control data and header section of an interim (1xx) HTTP response (see HTTP). <del> A HEADERS frame with an END_STREAM flag that carries an informational status code is malformed. </del> <ins> A HEADERS frame with the END_STREAM flag set that carries an informational status code is malformed. </ins> The last frame in the sequence bears an END_STREAM flag, noting that <del> a HEADERS frame bearing the END_STREAM flag can be followed by </del> <ins> a HEADERS frame with the END_STREAM flag set can be followed by </ins> CONTINUATION frames that carry any remaining fragments of the field block.
Code change:
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.

Related discussion:
text: An HTTP request/response exchange fully consumes a single stream.  A request starts with the HEADERS frame that puts the stream into an <del> "open" state.  The request ends with a frame bearing END_STREAM, which causes the stream to become "half-closed (local)" for the </del> <ins> "open" state.  The request ends with a frame with the END_STREAM flag set, which causes the stream to become "half-closed (local)" for the </ins> client and "half-closed (remote)" for the server.  A response stream starts with zero or more interim responses in HEADERS frames or a HEADERS frame containing a final status code.
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <ins> and ends with a frame with the END_STREAM flag set, which places the stream in the "closed" state. </ins> 8.5.
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <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.
Code change:
... 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.)

Related discussion:
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> <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.
Code change:
... 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.)

Related discussion:
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