jiebi/CodeConvo huggingface dataset:
Change:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)

Discussion:
packets larger than the smallest allowed maximum packet size of 1200 bytes. <ins> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 IPv4, the DF bit MUST be set to prevent fragmentation on the path. 14.1. </ins> A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by

client believes that the network path and peer both support the size that it chooses. <del> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 IPv4, the DF bit MUST be set to prevent fragmentation on the path. </del> A server MUST discard an Initial packet that is carried in a UDP datagram with a payload that is less than the smallest allowed maximum packet size of 1200 bytes.  A server MAY also immediately

The server MUST also limit the number of bytes it sends before validating the address of the client; see address-validation. <del> 14.1. </del> <ins> 14.2. </ins> The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP packet including the IP header, UDP header, and UDP

maximum packet size to allow for unknown tunnel overheads or IP header options/extensions. <del> 14.1.1. </del> <ins> 14.2.1. </ins> Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big

QUIC's loss detection algorithm determines that the quoted packet has actually been lost. <del> 14.2. </del> <ins> 14.3. </ins> Datagram Packetization Layer PMTU Discovery (DPLPMTUD; DPLPMTUD) relies on tracking loss or acknowledgment of QUIC packets that are

QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD MPS) for each combination of local and remote IP addresses. <del> 14.2.1. </del> <ins> 14.3.1. </ins> From the perspective of DPLPMTUD, QUIC transport is an acknowledged packetization layer (PL).  A sender can therefore enter the DPLPMTUD BASE state when the QUIC connection handshake has been completed. <del> 14.2.2. </del> <ins> 14.3.2. </ins> QUIC provides an acknowledged PL, therefore a sender does not implement the DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD. <del> 14.2.3. </del> <ins> 14.3.3. </ins> An endpoint using DPLPMTUD requires the validation of any received ICMP Packet Too Big (PTB) message before using the PTB information,

The considerations for processing ICMP messages described in pmtud also apply if these messages are used by DPLPMTUD. <del> 14.3. </del> <ins> 14.4. </ins> PMTU probes are ack-eliciting packets.

consume congestion window, which could delay subsequent transmission by an application. <del> 14.3.1. </del> <ins> 14.4.1. </ins> Endpoints that rely on the destination connection ID for routing incoming QUIC packets are likely to require that the connection ID be
Change:
Taking Gorry's suggestions, which seem quite reasonable.
(1) NiT: /The ECN counter for the ECN codepoint received in the associated IP header are incremented once for each QUIC packet, not per enclosing IP packet or UDP datagram./ mixed singular and plural - is this /counters/? (2) I like this phrase in the security considerations also from the point of view of how to generate transport feedback for ECT(?). Can we call this out here: /QUIC endpoints ignore the ECN codepoint field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed/ (3) General experiments are not permitted in RFC8311, only using experimental RFCs. I think therefore, we should be clear in the detail here: /Implementations MAY experiment with and use other strategies for use of ECN. Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations can also use the ECT(1) codepoint, as specified in {{?RFC8311}}./ I’d propose something more like this: /Other methods of probing paths for ECN support are possible, as are different marking strategies. Implementations MAY use other methods defined in RFCs, as specified in {{?RFC8311}}. Implementations that use the ECT(1) codepoint, need to perform ECN validation using this code point./

Discussion:
read the ECN codepoints from the enclosing IP packet, which is not possible on all platforms. <del> A packet detected by a receiver as a duplicate does not affect the receiver's local ECN codepoint counts; see (security-ecn) for relevant security concerns. </del> <ins> An IP packet that results in no QUIC packets being processed does not increase ECN counts.  A QUIC packet detected by a receiver as a duplicate does not affect the receiver's local ECN codepoint counts; see security-ecn for relevant security concerns. </ins> If an endpoint receives a QUIC packet without an ECT or CE codepoint in the IP packet header, it responds per generating-acks with an ACK

codepoints, it does not increase ECN counts. Coalesced packets (see packet-coalesce) mean that several packets can <del> share the same IP header.  The ECN counter for the ECN codepoint </del> <ins> share the same IP header.  The ECN counts for the ECN codepoint </ins> received in the associated IP header are incremented once for each QUIC packet, not per enclosing IP packet or UDP datagram.

codepoint for only the first ten outgoing packets on a path, or for a period of three RTTs, whichever occurs first. <del> Implementations MAY experiment with and use other strategies for use of ECN.  Other methods of probing paths for ECN support are possible, as are different marking strategies.  Implementations can also use the ECT(1) codepoint, as specified in RFC8311. </del> <ins> Other methods of probing paths for ECN support are possible, as are different marking strategies.  Implementations MAY use other methods defined in RFCs; see RFC8311.  Implementations that use the ECT(1) codepoint need to perform ECN validation using ECT(1) counts. </ins> 13.4.2.2.
Change:
The first inverts the description of "ih" to be clearer. The second makes it clearer for IANA that the "packets" column can be ignored.

Discussion:
1-RTT (short-header) <del> A CONNECTION_CLOSE frame of type 0x1d cannot appear in Initial or Handshake packets. </del> <ins> Only a CONNECTION_CLOSE frame of type 0x1c can appear in Initial or Handshake packets. </ins> Section 4 of QUIC-TLS provides more detail about these restrictions. Note that all frames can appear in 1-RTT packets.

format and assigned semantics of any fields in the frame. The initial contents of this registry are tabulated in frame-types. <ins> Note that the registry does not include the "Packets" column from frame-types. </ins> 22.4.
Change:
The section for "Values of Transport Parameters for 0-RTT" specifies which parameters a client MUST or MUST NOT remember. It does not do the same for a server. (It implies that ones a client MUST NOT remember also don't need to be remembered by a server, and it lists a subset of the remaining as ones the server MUST remember.) This commit adds the remaining parameters to a list that the server need not remember.
This still looks good with the latest commit Jana pushed.
The "Values of Transport Parameters for 0-RTT" section lists some, but not all, of the transport parameters defined in the spec. As currently written, it is ambiguous whether a server needs to remember the parameters not listed. (A list of parameters that the client MUST NOT remember, and therefore the server need not remember, is provided, as well as a list that the server MUST remember so it doesn't lower limits.) As far as I understand the definitions of the remaining parameters, there isn't any need for a server to remember them. However, instead of requiring implementors to read through all of the transport parameter definitions and infer this on their own, it would be easier on implementors to spell this out in this section. (This is required for definitions of new parameters.)
I like the latest text!

Discussion:
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_uni. <ins> A server MAY store and recover the previously sent values of the max_idle_timout, max_udp_payload_size, and disable_active_migration parameters and reject 0-RTT if it selects smaller values.  Lowering the values of these parameters while also accepting 0-RTT data could degrade the performance of the connection.  Specifically, lowering the max_udp_payload_size could result in dropped packets leading to worse performance compared to rejecting 0-RTT data outright. </ins> A server MUST either reject 0-RTT data or abort a handshake if the implied values for transport parameters cannot be supported.
Change:
Actually, as 3.1 is "to bre removed before publication", the expansion and ref should be in 3.2.1.

Discussion:
An HTTP origin advertises the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 <del> ALTSVC frame (ALTSVC), using the ALPN token defined in connection- establishment. </del> <ins> ALTSVC frame (ALTSVC), using the Application Layer Protocol Negotiation (ALPN) RFC7301 token defined in connection-establishment. </ins> For example, an origin could indicate in an HTTP response that HTTP/3 was available on UDP port 50781 at the same hostname by including the
Change:
NAME should merge this.
I'm assuming that you checked the others, and therefore surprised we got the others right.

Discussion:
amount of data. Implementations MUST support buffering at least 4096 bytes of data <del> received in out of order CRYPTO frames.  Endpoints MAY choose to </del> <ins> received in out-of-order CRYPTO frames.  Endpoints MAY choose to </ins> allow more data to be buffered during the handshake.  A larger limit during the handshake could allow for larger keys or credentials to be exchanged.  An endpoint's buffer size does not need to remain
Change:
My WGLC feedback for -invariants is mostly nits, so I figured I'd go straight to a PR. There's one piece of this that might be non-editorial; feel free to kick to an issue if you prefer. In one section, we say that different versions "might" define authentication for VN packets. Later, we say that QUIC versions MUST define such a mechanism. Resolving in favor of the MUST, I've changed the other occurrence to a more definitive statement that QUIC versions do so.
Thanks Mike.

Discussion:
bytes in length.  Connection IDs are described in connection-id. The next byte contains the length in bytes of the Source Connection <del> ID field that follows it.  This length is encoded as a 8-bit unsigned integer.  The Source Connection ID field follows the Source </del> <ins> ID field that follows it.  This length is encoded as an 8-bit unsigned integer.  The Source Connection ID field follows the Source </ins> Connection ID Length field and is between 0 and 255 bytes in length. The remainder of the packet contains version-specific content.

fields, or a truncated Supported Version. Version Negotiation packets do not use integrity or confidentiality <del> protection.  A specific QUIC version might authenticate the packet as part of its connection establishment process. </del> <ins> protection.  Specific QUIC versions define mechanisms to authenticate the packet as part of the connection establishment process. </ins> An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID
Change:
Or MAY, but let's leave this probabilistic, because in practice there is no uncertainty: packets are protected. I've changed the header of the section because it isn't just about the header: the subsections are about the specific headers, but this one is about packets as a whole.

Discussion:
first byte being set; packets with a short header have that bit cleared. <ins> QUIC packets might be integrity protected, including the header. However, QUIC Version Negotiation packets are not integrity protected; see vn. </ins> Aside from the values described here, the payload of QUIC packets is version-specific and of arbitrary length.

QUIC versions are identified with a 32-bit integer, encoded in network byte order.  Version 0 is reserved for version negotiation <del> (see version-negotiation).  All other version numbers are potentially valid. </del> <ins> (see vn).  All other version numbers are potentially valid. </ins> The properties described in this document apply to all versions of QUIC.  A protocol that does not conform to the properties described
Change:
NAME raised the point that the following text might be misleading, since HTTP/1.1 allows pipelining: "HTTP/1.1 [HTTP11] is a TCP mapping which 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 motivates tolerance of variant behavior. Because each connection can transfer only a single HTTP request or response at a time in each direction, multiple parallel TCP connections are often used, reducing the ability of the congestion controller to effectively manage traffic between endpoints." NAME suggested the following text instead: "Because of limitations in how HTTP exchanges are mapped onto TCP connections in HTTP/1.1, multiple parallel connections are often used..." NAME suggested the following text instead: "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."
Roy's works for me.

Discussion:
HTTP/1.1 HTTP11 is a TCP mapping which uses whitespace-delimited text fields to convey HTTP messages.  While these exchanges are human- readable, using whitespace for message formatting leads to parsing <del> complexity and motivates tolerance of variant behavior.  Because each connection can transfer only a single HTTP request or response at a time in each direction, multiple parallel TCP connections are often used, reducing the ability of the congestion controller to effectively manage traffic between endpoints. </del> <ins> complexity and motivates 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. </ins> HTTP/2 HTTP2 introduced a binary framing and multiplexing layer to improve latency without modifying the transport layer.  However,
Change:
We've been pretty disciplined about using "connection ID", except for the text on flow labels and one mention in the diagram for preferred_address. Of course, the mentions in the flow label text were specifically for the "Destination Connection ID field", so that is what I used there.
"Use of IPv6 Flow-Label and Migration" and the definition of "preferred_address" both reference "CID" without that abbreviation of Connection ID having been defined elsewhere. It's pretty obvious, but the text for IPv6 should probably just write out connection ID in long form.

Discussion:
The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the <del> destination CID.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as this would enable correlating activity on multiple paths; see migration-linkability. </del> <ins> Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as this would enable correlating activity on multiple paths; see migration-linkability. </ins> A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses, <del> source and destination UDP ports, destination CID, and a local secret. </del> <ins> source and destination UDP ports, Destination Connection ID field, and a local secret. </ins> 10.
Change:
In section 18.2, the definition of preferred_address says: In section 1.3, we say: The prose does not define the sequence of fields in this transport parameter.
Thanks for catching that I was looking at the wrong TP definition and knowing what I meant. Eyes glaze over indeed!

Discussion:
The server's preferred address is used to effect a change in server address at the end of the handshake, as described in <del> preferred-address.  The format of this transport parameter is shown in fig-preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family.  IP addresses are </del> <ins> preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family.  IP addresses are </ins> encoded in network byte order. <ins> The preferred_address transport parameter contains an address and port for both IP version 4 and 6.  The four-byte IPv4 Address field is followed by the associated two-byte IPv4 Port field. This is followed by a 16-byte IPv6 Address field and two-byte IPv6 Port field.  After address and port pairs, a Connection ID Length field describes the length of the following Connection ID field. Finally, a 16-byte Stateless Reset Token field includes the stateless reset token associated with the connection ID.  The format of this transport parameter is shown in fig-preferred- address. </ins> The Connection ID field and the Stateless Reset Token field contain an alternative connection ID that has a sequence number of 1; see issue-cid.  Having these values bundled with the preferred
Change:
The text here was perhaps a little unclear on this point. The point is that these don't carry information from server to client or client to server, they carry information from server (previous) to server (next).
There seems to be a conflict between this assertion in Section 9.2: URL the fact that 4.8 explicitly discusses how application protocols might need to have data embedded in the session ticket. (Also, QUIC doesn't use TLS address validation tokens.) I think this is actually trying to say that receipt of the session ticket MUST NOT cause side-effect beyond setting up the connection, but it's a broader prohibition than that.
I think that it says something else, namely that these are not intended to convey semantic information from client to server (or vice versa). PR inbound.

Discussion:
the application protocol that QUIC serves. TLS session tickets and address validation tokens are used to <del> carry QUIC configuration information between connections.  These MUST NOT be used to carry application semantics.  The potential for reuse of these tokens means that they require stronger protections against replay. </del> <ins> carry QUIC configuration information between connections. Specifically, to enable a server to efficiently recover state that is used in connection establishment and address validation.  These MUST NOT be used to communicate application semantics between endpoints; clients MUST treat them as opaque values.  The potential for reuse of these tokens means that they require stronger protections against replay. </ins> A server that accepts 0-RTT on a connection incurs a higher cost than accepting a connection without 0-RTT.  This includes higher
Change:
I came back to this today and found that the ordering was inconsistent and not sufficiently clear. Changing this so that all the actions for a single endpoint were grouped seemed to be the best arrangement. All events and actions are as close as possible in the ordering to the preceding event that caused or enabled it. The application data packets are displayed with a different marking, which helps distinguish those that carry CRYPTO frames. The final implied exchange for Get Handshake was removed. This was, I think, intended to imply something about session tickets. Without explanation, it is confusing. This doesn't show HANDSHAKE_DONE, nor do I think that it should, because that is something that the transport does once it gets the Handshake Complete signal.
LGTM, one suggestion

Discussion:
4.1.5. exchange-summary summarizes the exchange between QUIC and TLS for <del> both client and server.  Each arrow is tagged with the encryption level used for that transmission. </del> <ins> both client and server.  Solid arrows indicate packets that carry handshake data; dashed arrows show where application data can be sent.  Each arrow is tagged with the encryption level used for that transmission. </ins> exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what incoming messages trigger different actions.  New handshake messages <del> are requested after all incoming packets have been processed.  This process might vary depending on how QUIC implementations and the packets they receive are structured. </del> <ins> are requested after incoming packets have been processed.  This process varies based on the structure of endpoint implementations and the order in which packets arrive; this is intended to illustrate the steps involved in a single handshake exchange. </ins> 4.2.
Change:
As Magnus noted, the description of the first byte is missing, and I also noticed that the Supported Version field was described as following Version, which is wrong.
For -09 in WG LC. Section 6 has a packet header structure with the field: Unused (7) All the other fields are either fixed value or kind of defined earlier. In fact I would argue they represent concepts that are defined in -transport. Thus a second part of this is if -transport needs to be normative reference for the concepts used in this document. But back to Unused: I think this field can take any value on transmission, and should be ignored on reception. Maybe this needs to be noted explicitly in Section 6.
It's very deliberate that Invariants does not normatively depend on Transport. Invariants needs to stand alone, as a description of what versionless QUIC means. Arguably, Transport could normatively depend on Invariants, but it chooses instead to restate the things it depends on and make the reference informative.

Discussion:
defined in long-header.  A Version Negotiation packet is identifiable as such by the Version field, which is set to 0x00000000. <del> The Version Negotiation packet contains a list of Supported Version fields, each identifying a version that the endpoint sending the packet supports.  The Supported Version fields follow the Version field.  A Version Negotiation packet contains no other fields.  An endpoint MUST ignore a packet that contains no Supported Version fields, or a truncated Supported Version. </del> <ins> Only the most significant bit of the first byte of a Version Negotiation packet has any defined value.  The remaining 7 bits, labeled Unused, can be set to any value when sending and MUST be ignored on receipt. After the Source Connection ID field, the Version Negotiation packet contains a list of Supported Version fields, each identifying a version that the endpoint sending the packet supports.  A Version Negotiation packet contains no other fields.  An endpoint MUST ignore a packet that contains no Supported Version fields, or a truncated Supported Version. </ins> Version Negotiation packets do not use integrity or confidentiality protection.  Specific QUIC versions define mechanisms to authenticate