jiebi/CodeConvo huggingface dataset:
Change:
RFC-to-be 9114 (draft-ietf-quic-http) includes the following note to indicate that the registrations have a status of permanent and the Change Controller is the IETF. Should a similar statement be included in this document? From RFC-to-be 9114: The initial allocations in these registries created in this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (EMAIL). In addition, note that the padding in the Settings, Stream Types, and Error Codes differs from what appears in the IANA registry. IANA included the following note when they notified us that their actions for RFC-to-be 9114 were complete: NOTE: In the new registries, the padding has been adjusted for consistency from one registry to another and with URL We understand that there may be a request to change it. We have asked Mike (as editor of RFC-to-be 9114) to review, as the padding for the HTTP/3 registries is now inconsistent with the padding for the HTTP/2 registries. Please review and dicuss and let us know if any updates are needed.
Fixed in .
The QUIC registry policies, imported to HTTP/3, specify that a change controller and their contact information should be listed with each permanent registration. QPACK doesn't provide one, though almost certainly it should be the HTTP WG.

Discussion:
8. <ins> This document makes multiple registrations in the registries defined by HTTP3.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </ins> 8.1. This document specifies two settings.  The entries in the following
Change:
Rather than saying who ignores MAX_STREAMS, we can just that it is ignored.
has the following requirement: frame, advertising a smaller limit has no effect. A receiver MUST ignore any MAXSTREAMS frame that does not increase the stream limit. I believe this should be: frame, advertising a smaller limit has no effect. A sender MUST ignore any MAXSTREAMS frame that does not increase the stream limit. This would be in line with the similar requirements for MAXSTREAMDATA and MAXDATA in : is not an error to advertise a smaller limit, but the smaller limit has no effect. [...] A sender MUST ignore any MAXSTREAMDATA or MAXDATA frames that do not increase flow control limits.
I believe the sentence was intended to read: "A receiver(of the frame) MUST ignore any MAX_STREAMS frame that does not increase the stream limit."
Using "receiver" in this context is confusing, maybe it could just be replaced by "endpoint": frame, advertising a smaller limit has no effect. An endpoint MUST ignore any MAX_STREAMS frame that does not increase the stream limit. Or just take the language from : ignored.
Yeah, this is the right fix.

Discussion:
(error-handling). Once a receiver advertises a stream limit using the MAX_STREAMS <del> frame, advertising a smaller limit has no effect.  A receiver MUST ignore any MAX_STREAMS frame that does not increase the stream limit. </del> <ins> frame, advertising a smaller limit has no effect.  MAX_STREAMS frames that do not increase the stream limit MUST be ignored. </ins> As with stream and connection flow control, this document leaves implementations to decide when and how many streams should be
Change:
Tommy points out that we accidentally cited the sending parts, but these are receive states.
Very editorial nit: The section has the following text: The states referenced here are in fact receive stream states, not send stream states. Should this be: The same goes for MAXSTREAM_DATA:

Discussion:
STOP_SENDING requests that a peer cease transmission on a stream. A STOP_SENDING frame can be sent for streams in the Recv or Size <del> Known states; see stream-send-states.  Receiving a STOP_SENDING frame </del> <ins> Known states; see stream-recv-states.  Receiving a STOP_SENDING frame </ins> for a locally-initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR.  An endpoint that receives a STOP_SENDING frame for a receive-only stream

a peer of the maximum amount of data that can be sent on a stream. A MAX_STREAM_DATA frame can be sent for streams in the Recv state; <del> see stream-send-states.  Receiving a MAX_STREAM_DATA frame for a </del> <ins> see stream-recv-states.  Receiving a MAX_STREAM_DATA frame for a </ins> locally-initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR.  An endpoint that receives a MAX_STREAM_DATA frame for a receive-only
Change:
This avoids the implication of a single error code space. Even if one is permissible, that is not necessary.
NAME originally posted in URL a comment highlighting that although HTTP/3 uses a single error code space for connection and stream errors, there is no requirement for other application protocol mappings to do the same. I found the text in URL to give me the wrong assumptions. This is the only mention of an error code space in the text that will make it into RFC. So I suggest in the offending paragraph we delete the 2 occurrences of "space" and just state that the frame contains a value, either defined in transport [ref] or application [ref]
"uses codes defined by the application protocol"?

Discussion:
A variable-length integer error code that indicates the reason for closing this connection.  A CONNECTION_CLOSE frame of type 0x1c uses codes from the space defined in transport-error-codes.  A <del> CONNECTION_CLOSE frame of type 0x1d uses codes from the application protocol error code space; see app-error-codes. </del> <ins> CONNECTION_CLOSE frame of type 0x1d uses codes defined by the application protocol; see app-error-codes. </ins> A variable-length integer encoding the type of frame that triggered the error.  A value of 0 (equivalent to the mention of
Change:
These were not the same, even for the same items, so I fixed that. Checked with: Which shows the three items that are only present in -transport (-invariants doesn't use these).

Discussion:
Indicates that x is A bits long Indicates that x can be any length from A to B; A can be omitted <del> to indicate a minimum of zero bits and B can be omitted to </del> <ins> to indicate a minimum of zero bits, and B can be omitted to </ins> indicate no set upper limit; values in this format always end on a byte boundary <del> Indicates that x, with a length described by L, has a fixed value of C </del> <ins> Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above </ins> <del> Indicates that x is repeated zero or more times (and that each instance is length L) </del> <ins> Indicates that x is repeated zero or more times and that each instance has a length of L </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.

Indicates that x is A bits long Indicates that x holds an integer value using the variable-length <del> encoding in </del> <ins> encoding described in </ins> Indicates that x can be any length from A to B; A can be omitted <del> to indicate a minimum of zero bits and B can be omitted to </del> <ins> to indicate a minimum of zero bits, and B can be omitted to </ins> indicate no set upper limit; values in this format always end on a byte boundary <del> Indicates that x has a fixed value of C with the length described by L, which can use any of the three length forms above </del> <ins> Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above </ins> Indicates that x has a value in the range from C to D, inclusive, with the length described by L, as above <del> Indicates that x is optional (and has length of L) </del> <ins> Indicates that x is optional and has a length of L </ins> <del> Indicates that zero or more instances of x are present (and that each instance is length L) </del> <ins> Indicates that x is repeated zero or more times and that each instance has a length of L </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.
Change:
3) [rfced] Does the following improve the readability of the paragraph? Current: Endpoints SHOULD set the minrtt to the newest RTT sample after persistent congestion is established. This is to allow a connection to reset its estimate of minrtt and smoothedrtt after a disruptive network event (Section 5.3), and because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared. Perhaps: Endpoints SHOULD set the minrtt to the newest RTT sample after persistent congestion is established because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared. This also allows a connection to reset its estimate of minrtt and smoothedrtt after a disruptive network event (Section 5.3).
I find this easier to read, but I think it may be subtly different, so I put it into a separate PR.
It doesn't change the meaning, but it does feel like the first sentence is trying to span too many topics. I like the reordering, but I'd split it out.This is good, thank you !

Discussion:
the new RTT to be included in smoothed_rtt. Endpoints SHOULD set the min_rtt to the newest RTT sample after <del> persistent congestion is established.  This is to allow a connection to reset its estimate of min_rtt and smoothed_rtt (smoothed-rtt) after a disruptive network event, and because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared. </del> <ins> persistent congestion is established.  This avoids repeatedly declaring persistent congestion when the RTT increases.  This also allows a connection to reset its estimate of min_rtt and smoothed_rtt after a disruptive network event; see smoothed-rtt. </ins> Endpoints MAY re-establish the min_rtt at other times in the connection, such as when traffic volume is low and an acknowledgment
Change:
For this document, I believe the best option is to use "Application Data" when referring to the packet number space, and "application data" when referring to generic application data, such as when discussing being app-limited due to lack of application data. 6) [rfced] Throughout the text, the following term appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. application data / Application Data Note that RFC-to-be 9000 uses the lowercase form consistently. We raised a similar question for RFC-to-be 9001; the authors decided on the following: (see URL)

Discussion:
flight, the timer MUST be set to the earlier value of the Initial and Handshake packet number spaces. <del> An endpoint MUST NOT set its PTO timer for the application data </del> <ins> An endpoint MUST NOT set its PTO timer for the Application Data </ins> packet number space until the handshake is confirmed.  Doing so prevents the endpoint from retransmitting information in packets when either the peer does not yet have the keys to process them or the
Change:
Do you need to rebase? There's a change that seems to have been repeated in a previously merged PR.

Discussion:
QUIC aims to constrain the capabilities of an on-path attacker as follows: <del> An on-path attacker can prevent use of a path for a connection, causing the connection to fail if it cannot use a different path that does not contain the attacker.  This can be achieved by dropping all packets, modifying them so that they fail to decrypt, or other methods. </del> <ins> An on-path attacker can prevent the use of a path for a connection, causing the connection to fail if it cannot use a different path that does not contain the attacker.  This can be achieved by dropping all packets, modifying them so that they fail to decrypt, or other methods. </ins> An on-path attacker can prevent migration to a new path for which the attacker is also on-path by causing path validation to fail on
Change:
The repeated "when" clauses in this sentence make it difficult to parse. If our suggestion does not correctly capture your intent, could you please rephrase? Original: A stream becomes unblocked when the Insert Count becomes unblocked when the Insert Count becomes greater than or equal to the Required Insert Count for all encoded field sections the decoder has started reading from the stream. Perhaps: A stream becomes unblocked when the Insert Count becomes unblocked. When the Insert Count becomes greater than or equal to the Required Insert Count for all encoded field sections, the decoder has started reading from the stream.
It actually looks as though the words "becomes unblocked when the Insert Count" are duplicated, which would make the corrected text: That might still be confusing, but the proposed text certainly isn't the right change. The key point to capture is: The decoder has started reading at least one encoded field section from the stream and encountered a Required Insert Count value in some or all of them which exceeds its current Insert Count. This caused the stream to be considered blocked. When the Insert Count is greater than or equal to the RIC value from all of the encoded field sections the decoder has attempted to process, the stream becomes unblocked.
Fixed in .
Good catch.

Discussion:
the stream becomes unblocked, and releasing the flow control prematurely makes the decoder vulnerable to memory exhaustion attacks.  A stream becomes unblocked when the Insert Count becomes <del> unblocked when the Insert Count becomes greater than or equal to the Required Insert Count for all encoded field sections the decoder has started reading from the stream. </del> <ins> greater than or equal to the Required Insert Count for all encoded field sections the decoder has started reading from the stream. </ins> When processing encoded field sections, the decoder expects the Required Insert Count to equal the lowest possible value for the
Change:
Noticed in URL that we're pointing to different sections: 6.1 is the Transfer-Encoding header 7.1 is specifically 7 is transfer codings in general Since this passage is referring to the concept in general not being present in HTTP/3, Section 7 is the correct reference.

Discussion:
the message exchange, they must be received and processed before the message can be consumed.  See header-formatting for more details. <del> Transfer codings (see Section 6.1 of HTTP11) are not defined for </del> <ins> Transfer codings (see Section 7 of HTTP11) are not defined for </ins> HTTP/3; the Transfer-Encoding header field MUST NOT be used. A response MAY consist of multiple messages when and only when one or
Change:
This looks great to me.
NAME that's a good point. Let me reword it to use the operation terms rather than the v1 frame names.
From ... : URL be improved in h3. Not the TCP RST part, but the bit that leads up to it. Otherwise, we might not get the right behaviour. If the proxy just closes the connection in response to RESET_STREAM, it might then just end the stream (with a FIN bit), which would be wrong. Perhaps instead: Somewhat substantive, unfortunately, and very, very, very late. I'm happy to wait and file an erratum.
This seems like a solid improvement, but it's definitely not editorial. NAME and NAME will need to decide whether this is a change they're willing to accept post-IESG.
Endpoints that overlook the proposed behaviour risk zombie streams. This seems like something worth addressing while we have the opportunity. Can one of you please file create a PR and we'll take it to the AD.
Closed in .
Better than my text :)This looks ready to go, are we merging it soon?

Discussion:
A TCP connection error is signaled by abruptly terminating the stream.  A proxy treats any error in the TCP connection, which includes receiving a TCP segment with the RST bit set, as a stream <del> error of type H3_CONNECT_ERROR; see errors.  Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection.  If the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set. </del> <ins> error of type H3_CONNECT_ERROR; see errors. Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection.  If the proxy detects that the client has reset the stream or aborted reading from the stream, it MUST close the TCP connection.  If the stream is reset or reading is aborted by the client, a proxy SHOULD perform the same operation on the other direction in order to ensure that both directions of the stream are cancelled.  In all these cases, if the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set. </ins> Since CONNECT creates a tunnel to an arbitrary server, proxies that support CONNECT SHOULD restrict its use to a set of known ports or a
Change:
NAME observed a seeming conflict in the requirements around unknown unidirectional stream types. Section 9 says: This has two problems. First and editorial, if the type is unknown/unsupported, the presence of frames can't be determined. This should refer to discarding any data, not frames specifically. Second, it appears to disagree with Section 6.2: I think the intent was MUST abort, but MAY pick an error code. Looking at the history of the commits in Section 6.2, it was first MUST abort, then SHOULD use a particular code, then became MAY use the specific code with the prohibition on blowing up the whole connection. The text should clarify the scope of the MAY.
Agree. This change would meet the intent of the text and is editorial. So it the proposal here something like:
I think I'd say "MUST either abort reading of the stream or discard incoming data without further processing. If reading is aborted, the recipient SHOULD use...."
That would work for me too, care to make a PR?
Closed in .
LGTM thank you

Discussion:
If the stream header indicates a stream type that is not supported by the recipient, the remainder of the stream cannot be consumed as the <del> semantics are unknown.  Recipients of unknown stream types MAY abort reading of the stream with an error code of H3_STREAM_CREATION_ERROR or a reserved error code (http-error-codes), but the recipients MUST NOT consider such streams to be a connection error of any kind. </del> <ins> semantics are unknown.  Recipients of unknown stream types MUST either abort reading of the stream or discard incoming data without further processing.  If reading is aborted, the recipient SHOULD use the H3_STREAM_CREATION_ERROR error code or a reserved error code (http-error-codes).  The recipient MUST NOT consider unknown stream types to be a connection error of any kind. </ins> As certain stream types can affect connection state, a recipient SHOULD NOT discard data from incoming unidirectional streams prior to

and stream types (iana-stream-types). Implementations MUST ignore unknown or unsupported values in all <del> extensible protocol elements.  Implementations MUST discard frames and abort reading on unidirectional streams that have unknown or </del> <ins> extensible protocol elements.  Implementations MUST discard data or abort reading on unidirectional streams that have unknown or </ins> unsupported types.  This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation.  However, where a known frame type is required to be in
Change:
The RFC Editor asks:
Along the way, there are two equivalent statements that need to be deduplicated that this change touches: I would suggest collapsing these two into the first statement, but using OPTIONS as an example and keeping the reference into http-core. Or perhaps that should be a question -- is there a difference between asterisk-form and OPTIONS-without-path?
Resolved in .

Discussion:
more cookie-pairs, before compression.  If a decompressed field section contains multiple cookie field lines, these MUST be concatenated into a single byte string using the two-byte delimiter <del> of 0x3b, 0x20 (the ASCII string "; ") before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application. </del> <ins> of "; " (ASCII 0x3b, 0x20) before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application. </ins> 4.2.2.

4.3. Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where <del> the field name begins with the ':' character (ASCII 0x3a).  These </del> <ins> the field name begins with the ":" character (ASCII 0x3a).  These </ins> pseudo-header fields convey message control data; see HTTP. Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT

Similarly, HTTP/3 can transport field values that are not valid. While most values that can be encoded will not alter field parsing, <del> carriage return (CR, ASCII 0x0d), line feed (LF, ASCII 0x0a), and the zero character (NUL, ASCII 0x00) might be exploited by an attacker if they are translated verbatim.  Any request or response that contains a character not permitted in a field value MUST be treated as malformed (malformed).  Valid characters are defined by the "field- content" ABNF rule in HTTP. </del> <ins> carriage return (ASCII 0x0d), line feed (ASCII 0x0a), and the null character (ASCII 0x00) might be exploited by an attacker if they are translated verbatim.  Any request or response that contains a character not permitted in a field value MUST be treated as malformed (malformed).  Valid characters are defined by the "field-content" ABNF rule in HTTP. </ins> 10.4.
Change:
NAME was helpful enough to show me how to do this in URL, so now singular and plural versions of the same term are a single index entry.

Discussion:
and structure of data that follows this integer is determined by the stream type. <del> Two stream types are defined in this document: control streams (control-streams) and (push-streams).  RFC9204 defines two additional stream types.  Other stream types can be defined by extensions to HTTP/3; see extensions for more details.  Some stream types are reserved (stream-grease). </del> <ins> Two stream types are defined in this document: (control-streams) and (push-streams).  RFC9204 defines two additional stream types.  Other stream types can be defined by extensions to HTTP/3; see extensions for more details.  Some stream types are reserved (stream-grease). </ins> The performance of HTTP/3 connections in the early phase of their lifetime is sensitive to the creation and exchange of data on

If an entire connection needs to be terminated, QUIC similarly provides mechanisms to communicate a reason; see QUIC-TRANSPORT. <del> This is referred to as a "".  Similar to stream errors, an HTTP/3 implementation can terminate a QUIC connection and communicate the reason using an error code from http-error-codes. </del> <ins> This is referred to as a "".  Similar to , an HTTP/3 implementation can terminate a QUIC connection and communicate the reason using an error code from http-error-codes. </ins> Although the reasons for closing streams and connections are called "errors", these actions do not necessarily indicate a problem with

CANCEL_PUSH connection error control stream <del> control streams control streams </del> D DATA