jiebi/CodeConvo huggingface dataset:
Change:
Ian is right, we would lose the Initial discard condition. Drop the Handshake key drop condition.
NAME -- you're right, but I think that only applies to Initial here, since hs confirmed is the same as hs keys getting dropped. Take a look at the new text.
NAME said:
Yes, this should be only about handshake confirmation. Thanks for catching this!

Discussion:
certificate and can therefore read these 1-RTT packets. A sender SHOULD restart its PTO timer every time an ack-eliciting <del> packet is sent or acknowledged, when the handshake is confirmed (Section 4.1.2 of QUIC-TLS), or when Initial or Handshake keys are </del> <ins> packet is sent or acknowledged, or when Initial or Handshake keys are </ins> discarded (Section 4.9 of QUIC-TLS).  This ensures the PTO is always set based on the latest estimate of the round-trip time and for the correct packet across packet number spaces.
Change:
Roman Danyliw said:
I believe the mapping from encryption level to PNS is detailed in section 12.3 of transport: URL
I can't find the text being commented on.
NAME text is in the first paragraph of URL
It might be useful to point to the specific section in -transport that NAME mentioned in his comment. Anyone care to propose a PR?

Discussion:
All transmissions in QUIC are sent with a packet-level header, which indicates the encryption level and includes a packet sequence number (referred to below as a packet number).  The encryption level <del> indicates the packet number space, as described in QUIC-TRANSPORT. Packet numbers never repeat within a packet number space for the lifetime of a connection.  Packet numbers are sent in monotonically increasing order within a space, preventing ambiguity. </del> <ins> indicates the packet number space, as described in Section 12.3 of QUIC-TRANSPORT.  Packet numbers never repeat within a packet number space for the lifetime of a connection.  Packet numbers are sent in monotonically increasing order within a space, preventing ambiguity. </ins> This design obviates the need for disambiguating between transmissions and retransmissions; this eliminates significant
Change:
This seems to have caused problems, so address it.
This text in seems to cause confusion for implementors: since it leaves it unclear what the Initial packet can be coalesced with to pad it. Specifically, some implementations use zeros or other (random) data, which seems to surprise some implementors. (, which is referred to, also doesn't seem to clarify this.)
My understanding is that transport draft does not say anything about padding outside QUIC packet. Because a receiver is required to ignore invalid long packets, zero padding outside QUIC packet just works. So this is "OK because it is not explicitly disallowed" category.
I agree, but it has tripped up implementers (again). I wonder if a wording can be found that doesn't do that.
I'd be happy to see a bit more explicit text to clarify this, since as you said, it's come up a few times as non-obvious.
Maybe something like: "An Initial that is padded by coalescing could be coalesced with valid or even invalid QUIC packets; the latter MUST be ignored as described in Section XYZ."

Discussion:
A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes by adding PADDING frames to the Initial packet or <del> by coalescing the Initial packet; see packet-coalesce.  Similarly, a server MUST expand the payload of all UDP datagrams carrying ack- eliciting Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes.  Sending UDP datagrams of this size ensures that the network path supports a reasonable Path Maximum Transmission Unit (PMTU), in both directions.  Additionally, a client that expands Initial packets helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address-validation. </del> <ins> by coalescing the Initial packet; see packet-coalesce.  Initial packets can even be coalesced with invalid packets, which a receiver will discard.  Similarly, a server MUST expand the payload of all UDP datagrams carrying ack-eliciting Initial packets to at least the smallest allowed maximum datagram size of 1200 bytes. Sending UDP datagrams of this size ensures that the network path supports a reasonable Path Maximum Transmission Unit (PMTU), in both directions.  Additionally, a client that expands Initial packets helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address- validation. </ins> Datagrams containing Initial packets MAY exceed 1200 bytes if the sender believes that the network path and peer both support the size
Change:
I opted to reframe the language from HTTP/3 endpoint to decoder, since encoder and decoder instances are what this spec primarily talks about. We already say that HTTP/3 endpoints contain both an encoder and a decoder. I also added a comment that encoders track the contents of the table at the decoder. I specifically did not say that they keep a full copy of the table, however; they might not.
NAME said:
NAME said:

Discussion:
3.2. The dynamic table consists of a list of field lines maintained in <del> first-in, first-out order.  Each HTTP/3 endpoint holds a dynamic table that is initially empty.  Entries are added by encoder instructions received on the encoder stream; see encoder- instructions. </del> <ins> first-in, first-out order.  A QPACK encoder and decoder share a dynamic table that is initially empty.  The encoder adds entries to the dynamic table and sends them to the decoder via instructions on the encoder stream; see encoder-instructions. </ins> The dynamic table can contain duplicate entries (i.e., entries with the same name and same value).  Therefore, duplicate entries MUST NOT

The size of the dynamic table is the sum of the size of its entries. The size of an entry is the sum of its name's length in bytes, its <del> value's length in bytes, and 32.  The size of an entry is calculated using the length of its name and value without Huffman encoding applied. </del> <ins> value's length in bytes, and 32 additional bytes.  The size of an entry is calculated using the length of its name and value without Huffman encoding applied. </ins> 3.2.2.
Change:
Address multiple editorial comments.
NAME said
NAME said
The text currently says: Transport makes the following addition, in : That might be worth reiterating in HTTP/3.
NAME said
Two separate questions. I'm fine generalizing it to HTTP/1.x. The link between the first two sentences is the fact that HTTP/1.x uses human-readable whitespace-delimited fields, but those attributes make parsing inconsistent; subsequent versions of HTTP/2 went a different direction. If you're talking about the second and third, that could easily be a paragraph split; it's a change of idea under the umbrella of major changes of direction from H1 to H2+.

Discussion:
HTTP semantics (SEMANTICS) are used for a broad range of services on the Internet.  These semantics have most commonly been used with <del> HTTP/1.1, over a variety of transport and session layers, and with HTTP/2 over TLS.  HTTP/3 supports the same semantics over a new </del> <ins> HTTP/1.1 and HTTP/2.  HTTP/1.1 has been used over a variety of transport and session layers, while HTTP/2 has been used primarily with TLS over TCP.  HTTP/3 supports the same semantics over a new </ins> transport protocol, QUIC. 1.1.

HTTP/1.1 (HTTP11) uses whitespace-delimited text fields to convey HTTP messages.  While these exchanges are human-readable, using whitespace for message formatting leads to parsing complexity and <del> excessive tolerance of variant behavior.  Because HTTP/1.x does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel.  However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections. </del> <ins> excessive tolerance of variant behavior. Because HTTP/1.1 does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel.  However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections. </ins> HTTP/2 (HTTP2) introduced a binary framing and multiplexing layer to improve latency without modifying the transport layer.  However,

same packet as the QUIC CONNECTION_CLOSE frame improves the chances of the frame being received by clients. <ins> If there are open streams that have not been explicitly closed, they are implicitly closed when the connection is closed; see Section 10.2 of QUIC-TRANSPORT. </ins> 5.4. For various reasons, the QUIC transport could indicate to the
Change:
Draft 34 changed notation from "octet" to "byte" in a few places, but forgot to change the article in two places.
Thanks, NAME

Discussion:
Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits and B can be omitted to <del> indicate no set upper limit; values in this format always end on an byte boundary </del> <ins> indicate no set upper limit; values in this format always end on a byte boundary </ins> Indicates that x, with a length described by L, has a fixed value of C

Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits and B can be omitted to <del> indicate no set upper limit; values in this format always end on an byte boundary </del> <ins> indicate no set upper limit; values in this format always end on a byte boundary </ins> 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
Change:
From the transport draft's connection migration section.
Section 9.4 in Transport(URL) does a nice job of explaining the RTT and congestion control implications of migration, but given one might reasonably expect some or all of that text to exist in recovery, I think it makes sense to reference it more. In particular, "Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path." is a useful sentence.

Discussion:
RTT samples for the network path are recorded in latest_rtt; see latest-rtt.  On the first RTT sample after initialization, the estimator is reset using that sample.  This ensures that the <del> estimator retains no history of past samples. </del> <ins> estimator retains no history of past samples.  Packets sent on other paths do not contribute RTT samples to the current path, as described in Section 9.4 of QUIC-TRANSPORT. </ins> On the first RTT sample after initialization, smoothed_rtt and rttvar are set as follows:

only packets being sent, but this document does not describe a mechanism for doing so. <ins> The congestion controller is per path, so packets sent on other paths do not alter the current path's congestion controller, as described in Section 9.4 of QUIC-TRANSPORT. </ins> The algorithm in this document specifies and uses the controller's congestion window in bytes.
Change:
Specifically those defined in RFC 7540.
URL says: The table of defined HTTP/3 settings is in URL The diverges a little bit from everything that is stated in RFC 7540. is stated as reserved in IANA but no mention of it in RFC 7540. Therefore it is ambiguous if an HTTP/3 implementation should reject this Type value. The range is reserved for HTTP/2 experimental use. Its not clear if I should reject those too. IANA also includes some extension settings: (RFC 8441), 0x10 (MS-HTTP2E). I might expect to be reused by some extension that defines Websocket over H3. seems like something that is not reusable? And finally, we have Extensible Priorities that defines SETTINGSDEPRECATEHTTP2_PRIORITIES and wants to claim . I don't expect any need to also define that in HTTP/3 settings, unless the purpose is to prohibit it. In summary, I don't think there is a huge problem. Maybe we can editorialize our way out of the ambiguity. However, I'd really like to avoid H/3 connections instantly failing due to implementations disagreeing about this rejection requirement.
I overlooked that NAME already made the point about in .
The intent is to reserve things that are defined in 7540; things reserved by other extensions might later be defined for HTTP/3, so there shouldn't be any assumptions. Let's make that requirement crisper to apply specifically to those values explicitly reserved.
WfM
I wonder if we should ask IANA if they can tell how it came to be that 0x0 was marked as reserved with 7540 as the reference even though we are failing to see what part of 7540 should be effectuating that.

Discussion:
Because the setting has no defined meaning, the value of the setting can be any value the implementation selects. <del> Setting identifiers which were used in HTTP/2 where there is no </del> <ins> Setting identifiers which were defined in HTTP2 where there is no </ins> corresponding HTTP/3 setting have also been reserved (iana-settings). <del> These settings MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_SETTINGS_ERROR. </del> <ins> These reserved settings MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_SETTINGS_ERROR. </ins> Additional settings can be defined by extensions to HTTP/3; see extensions for more details.
Change:
NAME said
NAME said
Honestly, this whole sentence is a bit awkward. I'll improve that.
NAME said
I have to say, this is a little odd. HTTP requires case insensitive comparison, but by calling it out here, the juxtaposition is weird. As we force lowercase, we could just strike: "that are compared in a case-insensitive fashion"
The first is a statement of fact about what SEMANTICS requires. However, I agree that we reduce confusion and lose nothing by making the statement less explicit. Interested parties can read SEMANTICS.
Yes, the proposed text addresses my comments. Thanks for the updates.

Discussion:
*Note:* This registry will not exist until SEMANTICS is approved. *RFC Editor*, please remove this note prior to publication. <del> As in previous versions of HTTP, field names are strings containing a subset of ASCII characters that are compared in a case-insensitive fashion.  Properties of HTTP field names and values are discussed in more detail in Section 5.1 of SEMANTICS.  As in HTTP/2, characters in </del> <ins> Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more detail in Section 5.1 of SEMANTICS.  As in HTTP/2, characters in </ins> field names MUST be converted to lowercase prior to their encoding. A request or response containing uppercase characters in field names MUST be treated as malformed (malformed).

4.1.1.2. <del> HTTP/3 uses QPACK field compression as described in QPACK, a variation of HPACK that allows the flexibility to avoid compression- induced head-of-line blocking.  See that document for additional details. </del> <ins> QPACK describes a variation of HPACK that gives an encoder some control over how much head-of-line blocking can be caused by compression.  This allows an encoder to balance compression efficiency with latency.  HTTP/3 uses QPACK to compress header and trailer sections, including the pseudo-header fields present in the header section. </ins> To allow for better compression efficiency, the "Cookie" field (RFC6265) MAY be split into separate field lines, each with one or

permit these streams to open, an HTTP/3 server SHOULD configure non- zero minimum values for the number of permitted streams and the initial stream flow control window.  So as to not unnecessarily limit <del> parallelism, at least 100 requests SHOULD be permitted at a time. </del> <ins> parallelism, at least 100 request streams SHOULD be permitted at a time. </ins> HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams.  Clients MUST treat
Change:
NAME said
One could imagine an implementation using a small buffer to read the beginning of the stream. If the whole field section happens to fit into it, so be it. A MUST would probably mean that a conforming implementation had to unread the field section.
We can probably just use "can" here. From an interoperability standpoint, there is no value to recommending any particular value.
Does SHOULD -> can mean this is a design change?
Yes, so if you're advocating doing that then I'll mark this as design.
The SHOULD is there to guard against memory exhaustion attacks. Streams "parking" is a QPACK design feature. The SHOULD should stay.
The plan is to leave the SHOULD, but add more editorial text in 2.2.1 explaining why it's a good idea.

Discussion:
processed immediately.  Otherwise, the stream on which the field section was received becomes blocked. <del> To bound the memory requirements of the decoder for blocked streams, encoded field section data SHOULD remain in the stream's flow control window while the stream is blocked.  A stream 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. </del> <ins> While blocked, encoded field section data SHOULD remain in the blocked stream's flow control window.  This data is unusable until 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 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. </ins> When processing encoded field sections, the decoder expects the Required Insert Count to equal the lowest possible value for the
Change:
Cleanup the language here a little.
This text could be better: Maybe instead:
Does anyone want to prepare a PR? Otherwise, this will get dropped I guess.
I didn't want to clutter our list of stuff with post-IESG PRs. I'll copy the above text once HTTP is done (real soon now). We're going to have to be careful that these little tweaks don't pile up.
I think this should be good to go now?

Discussion:
ClientHello message in their first Initial packet. The TLS implementation does not need to ensure that the ClientHello <del> is large enough to meet the requirements for QUIC packets.  QUIC PADDING frames are added to increase the size of the packet as necessary; see Section 14.1 of QUIC-TRANSPORT. </del> <ins> is large enough to meet QUIC's requirements for datagrams that carry Initial packets; see Section 14.1 of QUIC-TRANSPORT.  QUIC implementations use PADDING frames or packet coalescing to ensure that datagrams are large enough. </ins> 4.4.
Change:
Adds the all-important conditional.
For clients that have sent CANCEL_PUSH, they don't know if server's push stream will still arrive or not. They have to remember Push IDs forever in order to differentiate between cancelled push and completed push.
I would appreciate some quick discussion if this issue is important to address before I approve or not.
We could make this a MAY. The other formulation we've used is "MUST ... if the client detects", making the response mandatory if the condition is detected, but not specifying the required level of effort to detect it.
I don't know that this issue is critical to address, but I agree that with certain (reasonable) implementation strategies this particular MUST becomes unenforceable / unachievable.
+1 for "MUST if the client detects" if we're going to make a change.
I think "MUST if detects" is suitable here - it points at the core problem. Simply s/MUST/MAY doesn't help people appreciate that might not be able to detect the condition. I'd also suggest that "MUST if detects" is an editorial change.
NAME can you confirm if addresses your issue?
Looks good!
Thanks. In that case I believe we have addressed this issue with an editorial change. NAME please confirm if we can merge the related PR and incorporate the change in during the RFC editor process.
Yes, the change looks good. I could actually include it as an RFC-edtior note in my approval message.
An elegant solution :)

Discussion:
H3_STREAM_CREATION_ERROR; see errors. Each Push ID MUST only be used once in a push stream header.  If a <del> push stream header includes a Push ID that was used in another push stream header, the client MUST treat this as a connection error of type H3_ID_ERROR; see errors. </del> <ins> client detects that a push stream header includes a Push ID that was used in another push stream header, the client MUST treat this as a connection error of type H3_ID_ERROR; see errors. </ins> 6.2.3.
Change:
If the client has opened a stream in 0-RTT with , and the server increases to , does this apply to this stream as well, or only to streams opened after handshake completion? Consensus in Slack seems to be that the limit should apply to all streams. The text should be explicit about that.
Isn't that already clear enough? states:
NAME This is what the definition of the TP says: Arguably, the stream used in 0-RTT is not a "newly created" stream.
Yeah, let's just be really clear about this. Though NAME quotes the section that is most important, this has proven to be a mistake common enough to spend text on.

Discussion:
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_uni. <ins> A server might provide larger initial stream flow control limits for streams than the remembered values that a client applies when sending 0-RTT.  Once the handshake completes, the client updates the flow control limits on all sending streams using the updated values of initial_max_stream_data_bidi_remote and initial_max_stream_data_uni. </ins> A server MAY store and recover the previously sent values of the max_idle_timeout, max_udp_payload_size, and disable_active_migration parameters and reject 0-RTT if it selects smaller values.  Lowering
Change:
as well as other instances of the term. RFC 7301 does indeed hyphenate (and that's correct, since "application-layer" is being used as a single unit to describe "protocol").
URL says the registry is

Discussion:
its first cryptographic handshake message, which for TLS is the ClientHello.  Servers might need to parse the entire ClientHello (e.g., to access extensions such as Server Name Identification (SNI) <del> or Application Layer Protocol Negotiation (ALPN)) in order to decide </del> <ins> or Application-Layer Protocol Negotiation (ALPN)) in order to decide </ins> whether to accept the new incoming QUIC connection.  If the ClientHello spans multiple Initial packets, such servers would need to buffer the first received fragments, which could consume excessive

Endpoints use transport parameters to authenticate the negotiation of connection IDs during the handshake; see cid-auth. <del> Application Layer Protocol Negotiation (ALPN; see ALPN) allows </del> <ins> Application-Layer Protocol Negotiation (ALPN; see ALPN) allows </ins> clients to offer multiple application protocols during connection establishment.  The transport parameters that a client includes during the handshake apply to all application protocols that the

validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection.  Unless some other mechanism is used to select <del> HTTP/3, the token "h3" is used in the Application Layer Protocol </del> <ins> HTTP/3, the token "h3" is used in the Application-Layer Protocol </ins> Negotiation (ALPN; see RFC7301) extension during the TLS handshake. Connectivity problems (e.g., blocking UDP) can result in QUIC

11.1. This document creates a new registration for the identification of <del> HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol </del> <ins> HTTP/3 in the "Application-Layer Protocol Negotiation (ALPN) Protocol </ins> IDs" registry established in RFC7301. The "h3" string identifies HTTP/3: