jiebi/CodeConvo huggingface dataset:
Change:
NAME see .
Section 11.2: URL "The initial allocations in these registries created in this document are all assigned permanent status and list as contact both the IESG (EMAIL) and the HTTP working group (EMAIL)." From my perspective it is better to have IETF as change controller. In practice that would mean that any chartered WG to work on this registry would by completing the IETF process be allowed to introduce changes to the registry. Having HTTP Working Group as contact is fine. So I would propose to change this to: "The initial allocations in these registries created in this document are all assigned permanent status and list as change controller the IETF and the HTTP working group (EMAIL) as contact."

Discussion:
Section 22.1.1 of QUIC-TRANSPORT. The initial allocations in these registries created in this document <del> are all assigned permanent status and list as contact both the IESG (iesg@ietf.org) and the HTTP working group (ietf-http-wg@w3.org). </del> <ins> are all assigned permanent status and list as contact both the IETF and the HTTP working group (ietf-http-wg@w3.org). </ins> 11.2.1.
Change:
At NAME suggestion this adds a "change controller" field to registries and splits between a change controller (IETF) and contact (QUIC WG). Not really sure if this is worth a design label...
Section 22.1.1: It is quite common that one may want to separate who has the change control over an registration entry vs who is the contact. Change control can often be assigned to an organization rather than an individual while a contact information may be an individual or a specific contact address for the organization. Contact information has a tendency to get stale, and in many case the contact if a person may no longer represent the organization that made the registration. Thus, my suggestion would be to add a separation between contact and change controller. In fact just for the registration in the Transport doc it makes sense to make the change controller "IETF" and have the contact be "QUIC WG".
This also applies to permanent registrations in Section 22.1.4
NAME does the PR address your issue?
Change looks good and implements what I proposed.
Labeling as "editorial" based on

Discussion:
The date of last update to the registration. <ins> The entity that is responsible for the definition of the registration. </ins> Contact details for the registrant. Supplementary notes about the registration.

permanent. All registrations in this document are assigned a permanent status <del> and list as contact the IETF (quic@ietf.org). </del> <ins> and list a change controller of the IETF and a contact of the QUIC working group (quic@ietf.org). </ins> 22.2.

Section 22.1.1 of QUIC-TRANSPORT. The initial allocations in these registries created in this document <del> are all assigned permanent status and list as contact both the IETF and the HTTP working group (ietf-http-wg@w3.org). </del> <ins> 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> 11.2.1.
Change:
Section 1.1: HTTP field line: A name-value pair sent as part of an HTTP field section. See Section 5 of [SEMANTICS]. I would guess that this can be refined to point to section 5.4.
Proposed change is "editorial".

Discussion:
fields; this document uses "fields" for generality. A name-value pair sent as part of an HTTP field section.  See <del> Section 5 of SEMANTICS. </del> <ins> Section 5.4 and Section 5.6 of SEMANTICS. </ins> Data associated with a field name, composed from all field line values with that field name in that section, concatenated together
Change:
Taken from NAME suggestion on the list.
On the mailing list NAME raised a question about pseudo-headers. That discussion seemed to identify that HTTP/3 oversteps the mark by saying that psuedo-headers are extensible. We can make an editorial change to bring this back to something equivalent to what RFC 7540 says. See .
Conversation evolved, I''ve created a PR that takes Mike's suggestion.

Discussion:
Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in this <del> document, except as negotiated via an extension; see extensions. </del> <ins> document; however, an extension could negotiate a modification of this restriction; see extensions. </ins> Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear
Change:
Section 4.1.2: Although this is summary of the definition in HPACK, where this issue is clear I think this document should describe things corretly. HPACK defines string literals to begin on a byte boundary. They begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data. When Huffman encoding is enabled, the Huffman table from Appendix B of [RFC7541] is used without modification. The length field as described here, provides an uncertainty if it is the data pre huffman (if applied) encoding or post encoding. HPACK is clear that it is the later. Can you please clarify that the length if the length of the encoded string that is encoded using N-bit prefix integer encoding. "An "N-bit prefix string literal" begins with the same Huffman flag, followed by the length encoded as an (N-1)-bit prefix integer." This definition if it is the byte or the prefix field that begins with the huffman flag. I would guess that what is meant is that a 6-bit prefix string literal would have a start byte of "??Hxxxxx" rather than "H??xxxxx".
This would be an "editorial" change.
Yes, the latter is correct. A prefixed string literal does not begin on a byte boundary; the first bit (when it begins) is the Huffman bit, and the remainder is a prefixed integer.

Discussion:
(indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data.  When Huffman encoding is enabled, the Huffman table from <del> Appendix B of RFC7541 is used without modification. </del> <ins> Appendix B of RFC7541 is used without modification and Length indicates the size of the string after encoding. </ins> This document expands the definition of string literals by permitting them to begin other than on a byte boundary.  An "N-bit prefix string <del> literal" begins with the same Huffman flag, followed by the length encoded as an (N-1)-bit prefix integer.  The prefix size, N, can have a value between 2 and 8 inclusive.  The remainder of the string literal is unmodified. </del> <ins> literal" begins mid-byte, with the first (8-N) bits allocated to a previous field.  The string uses one bit for the Huffman flag, followed by the Length encoded as an (N-1)-bit prefix integer.  The prefix size, N, can have a value between 2 and 8 inclusive.  The remainder of the string literal is unmodified. </ins> A string literal without a prefix length noted is an 8-bit prefix string literal and follows the definitions in RFC7541 without
Change:
are encoded as variable-length integers; see Section 16. A QUIC endpoint MUST NOT reuse a stream ID within a connection. This was a common problem throughout the text. I found the use of (0x1) and similar confusing in the text. Where you use this notation you mean the bit manipulated by the mask 0x1 (and similar). It would be helpful to the reader to be a little more pedantic in the use of the term in each case. We will get to it later, in the comments but a lot of readers would be helped by the use of the classic ASCII art style representation of bit fields.
slightly more text

Discussion:
For example: <ins> When a single-bit field is referenced in prose, the position of that field can be clarified by using the value of the byte that carries the field with the field's value set.  For example, the value 0x80 could be used to refer to the single-bit field in the most significant bit of the byte, such as One-bit Field in fig-ex-format. </ins> 2. Streams in QUIC provide a lightweight, ordered byte-stream
Change:
On endpoints.
This is the IPv6 minimum size ([IPv6]) and is also supported by most modern IPv4 networks. Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. The previous two paras are quite confusing. I think the first para refers to the max packet size in the network layer, but the second para is not clear, nor is the next para.
The paragraph preceding the first is this: So it is clear what the second paragraph means. QUIC doesn't operate if the network is incapable of carrying a datagram payload of 1200 bytes. I think that rewording that way might help. What is less clear is where the extra 32 (or 52) bytes go. In that we've been very generous in providing for header extensions or UDP extensions. But I don't see a need to explain that aspect.
I found this to still be very confusing, FWIW. It's unclear why the limit would be 1200 bytes when the text very clearly explains that at least 1232 can be relied upon, or alternatively why the text claims "QUIC assumes a minimum IP packet size of at least 1280 bytes." when in fact it appears to only mandate a 32 bytes smaller figure. It reads like someone forgot to update a constant. NAME above suggests that this was intentional, to leave space for unspecified future use by lower layers. I think some allusion to this is justified, just to clarify the otherwise seeming inconsistency.
A sentence to tie it together but LGTM

Discussion:
The maximum datagram size is defined as the largest size of UDP payload that can be sent across a network path using a single UDP <del> datagram. QUIC depends upon a minimum IP packet size of at least 1280 bytes. This is the IPv6 minimum size (IPv6) and is also supported by most modern IPv4 networks.  Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. The maximum datagram size MUST be at least 1200 bytes. </del> <ins> datagram.  QUIC MUST NOT be used if the network path cannot support a maximum datagram size of at least 1200 bytes. QUIC assumes a minimum IP packet size of at least 1280 bytes.  This is the IPv6 minimum size (IPv6) and is also supported by most modern IPv4 networks.  Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths will be able to support QUIC. </ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or
Change:
Fixed Bits (2) = 1, Unpredictable Bits (38..), Stateless Reset Token (128), } When I first met this my reaction was that I was sure it sends a lot more bits on the wire than this, but so far I have not see a packet definition nor a pointer to a packet definition. Please could you clarify what is happening?
This seems like a nit. I guess the only thing being that this is the first time the notation introduced in Section 1.3 is used. And now it is Section 10.3. I'll add a cross reference.

Discussion:
RETIRE_CONNECTION_ID frame (frame-retire-connection-id). An endpoint that receives packets that it cannot process sends a <del> packet in the following layout: </del> <ins> packet in the following layout (see notation): </ins> This design ensures that a stateless reset packet is - to the extent possible - indistinguishable from a regular packet with a short
Change:
Less detail above, but a pointer to what follows.

Table 3: Frame Types The notation used in the table took a while to figure out. A little more explanation, and possibly before the table itself might make it clearer.
One suggestion, but LGTM

Discussion:
Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields: <del> The frame types defined in this specification are listed in frame- types.  The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and CONNECTION_CLOSE frames is used to carry other frame-specific flags.  For all other frames, the Frame Type field simply identifies the frame.  These frames are explained in more detail in frame- formats. </del> <ins> frame-types lists and summarizes information about each frame type that is defined in this specification.  A description of this summary is included after the table. The format and semantics of each frame type are explained in more detail in frame-formats.  The remainder of this section provides a summary of important and general information. The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED, and CONNECTION_CLOSE frames is used to carry other frame-specific flags. For all other frames, the Frame Type field simply identifies the frame. </ins> The "Pkts" column in frame-types lists the types of packets that each frame type could appear in, indicated by the following characters:

An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR. <del> All QUIC frames are idempotent in this version of QUIC.  That is, a valid frame does not cause undesirable side effects or errors when received more than once. </del> <ins> All frames are idempotent in this version of QUIC.  That is, a valid frame does not cause undesirable side effects or errors when received more than once. </ins> The Frame Type field uses a variable-length integer encoding (see integer-encoding) with one exception.  To ensure simple and efficient
Change:
I struggled with this a little. Happy to take suggestions.
I'm going to say that the IP Packet vs. QUIC Packet text is not necessary. We carefully qualify where there is any potential for confusion.
On the other issue, it might be worth simply stating the terminology upfront. Something like


Datagram Size There is some confusion in the text between packets, frames and datagrams. That could be helped by earlier clarification.
This is a duplicate of .
12.4. Frames and Frame Types Packet Payload { Frame (8..) ..., } Version Negotiation, Stateless Reset, and Retry packets do not contain frames. At this point (page 82) I am still not sure what a packet or a frame is and have no idea what is going on on the wire.
Probably a duplicate of . These terms should be added to the definitions, with possibly some additional explanatory text in Section 12.
Section 1 is the first place that you introduce the term "Frame". I got very confused about frames and packets, and I thing the taxonomy needs to be clearly explained. You have UDP/IP packets that carry one or more QUIC PDUs, but the frame/packet notation made it unclear what was being discussed and whether the terms were being used consistently. Some clarification would be useful, or if it is in the text then making it more obvious would help.
Perhaps "frame" and "datagram" should be added as defined terms in Section 1.2. On a related note, the defined term is "QUIC packet" but in the text we don't always specify what type of "packet." Perhaps we should define "packet" as generally referring to QUIC, with a note that IP packets will be indicated as such. (I believe all instances of "packet" that refer to IP explicitly say "IP packet," but we should verify that.)
One small suggestion, which you can ignore if you don't like it.

Discussion:
The transport protocol described by this document.  QUIC is a name, not an acronym. <del> A complete processable unit of QUIC that can be encapsulated in a UDP datagram.  Multiple QUIC packets can be encapsulated in a single UDP datagram. A QUIC packet that contains frames other than ACK, PADDING, and CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment; see sending-acknowledgements. </del> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types of endpoint in QUIC: client and server.

The endpoint that accepts a QUIC connection. <ins> A complete processable unit of QUIC that can be encapsulated in a UDP datagram.  One or more QUIC packets can be encapsulated in a single UDP datagram. A QUIC packet that contains frames other than ACK, PADDING, and CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment; see sending-acknowledgements. A unit of structured protocol information.  There are multiple frame types, each of which carries different information.  Frames are contained in QUIC packets. </ins> When used without qualification, the tuple of IP version, IP address, and UDP port number that represents one end of a network path.
Change:
I took some liberties with data types here, but... pseudocode. I do wonder if the slice notation is sufficiently clear; I was hesitant to just do bit-shifts and masks because the number of bytes returned is key. An alternative would be simply to return the number of bytes, I suppose.
bit more than the base-2 logarithm of the number of contiguous unacknowledged packet numbers, including the new packet. That is really hard to parse. 0xabe8bc, sending a packet with a number of 0xac5c02 requires a packet number encoding with 16 bits or more; whereas the 24-bit packet number encoding is needed to send a packet with a number of 0xace8fe. and so is that. Indeed I found the remaining paras of the section difficult to follow.
I agree that first sentence is hard to parse.
I also agree regarding the first. As this is an alternative description, and I don't have anything better to offer, I plan not to change anything unless someone offers something good. The second seems fine.
I wonder if the real takeaway here is that these "examples in passing" assume the reader is deeply following along with the algorithm in their head; I know I don't, but I'm also not implementing packetization. We already have an appendix that illustrates packet number decoding; perhaps we should move one or both paragraphs to an appendix that illustrates selecting an encoding, with these as the examples. Reading the rest of the section, is "protection of the packet number" the term we've used elsewhere? Shouldn't that be "header protection," perhaps with a cross-ref to -tls?

Discussion:
As a result, the size of the packet number encoding is at least one bit more than the base-2 logarithm of the number of contiguous <del> unacknowledged packet numbers, including the new packet. For example, if an endpoint has received an acknowledgment for packet 0xabe8bc, sending a packet with a number of 0xac5c02 requires a packet number encoding with 16 bits or more; whereas the 24-bit packet number encoding is needed to send a packet with a number of 0xace8fe. </del> <ins> unacknowledged packet numbers, including the new packet.  Pseudo-code and examples for packet number encoding can be found in sample- packet-number-encoding. </ins> At a receiver, protection of the packet number is removed prior to recovering the full packet number.  The full packet number is then

Once header protection is removed, the packet number is decoded by finding the packet number value that is closest to the next expected packet.  The next expected packet is the highest received packet <del> number plus one.  For example, if the highest successfully authenticated packet had a packet number of 0xa82f30ea, then a packet containing a 16-bit value of 0x9b32 will be decoded as 0xa82f9b32. Example pseudo-code for packet number decoding can be found in sample-packet-number-decoding. </del> <ins> number plus one.  Pseudo-code and an example for packet number decoding can be found in sample-packet-number-decoding. </ins> 17.2.
Change:
if we decide we need/want it.
And yes, this handwaves over coercing the mask into the right size integer for the number of bytes you read.
When you do that, it's probably worth copying the "Code Components" language from -recovery.
hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). The Some hex & decimal indication would help. A picture is worth a thousand words and save the reader drawing this out themselves to understand it and getting confused. The conversion pseudo code would be helpful, possibly in an appendix.
I don't think that any change is needed here. It says "in hexadecimal" and "decimal value" right there.
We could put comma separators in the decimal values (i.e. 494878333 => 494,878,333) so they're more readily parsed as decimals rather than digit sequences. And an appendix with a varint decoder might not be the worst idea.

Discussion:
encode 6, 14, 30, or 62 bit values respectively.  integer-summary summarizes the encoding properties. <del> For example, the eight byte sequence c2 19 7c 5e ff 14 e8 8c (in hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). </del> <ins> Examples and a sample decoding algorithm are shown in sample-varint. </ins> Versions (versions) and packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding.
Change:
while the client 'spins' it after one RTT. On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. It would be clearer to the reader if the explanation of operation proceeded the detail.
This is fine, but I find that description to be less than ideal. I won't try to suggest an improvement though. It isn't so bad.

Discussion:
The latency spin bit enables passive latency monitoring from observation points on the network path throughout the duration of a <del> connection.  The spin bit is only present in the short packet header, since it is possible to measure the initial RTT of a connection by observing the handshake.  Therefore, the spin bit is available after version negotiation and connection establishment are completed.  On- path measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. </del> <ins> connection.  The server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. The spin bit is only present in the short packet header, since it is possible to measure the initial RTT of a connection by observing the handshake.  Therefore, the spin bit is available after version negotiation and connection establishment are completed.  On-path measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. </ins> The spin bit is an OPTIONAL feature of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in

An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path. <del> With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. </del> 18. The extension_data field of the quic_transport_parameters extension
Change:
This is right next to the BCP 14 text. (Based on private conversation with Joel Halpern who expressed the concern that this seems to lack overt normative force.)

Discussion:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document defines requirements on future QUIC versions, even where normative language is not used. </ins> This document uses terms and notational conventions from QUIC- TRANSPORT.