jiebi/CodeConvo huggingface dataset:
Code change:
This was always intended (and also written in the description of FRAMEENCODINGERROR), but didn't show up in the text somehow.
I agree with NAME about the MUSTs that you shuffled around are statements of fact, not interoperability requirements, but the addition is fine.

Related discussion:
text: the frame.  These frames are explained in more detail in frame- formats. <ins> An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR. </ins> 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.
Code change:
draft-ietf-quic-tls currently mentions AEADAES256CCM, however there is no way to use that AEAD in TLS 1.3 - TLSAES256CCMSHA256 does not appear in the . If I understand this correctly, the presence of AEADAES256CCM in the document was an editorial oversight.
Thanks. This was extremely confusing: you meant CCM, but wrote GCM in tons of places.

Related discussion:
text: Before a TLS ciphersuite can be used with QUIC, a header protection algorithm MUST be specified for the AEAD used with that ciphersuite. This document defines algorithms for AEAD_AES_128_GCM, <del> AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </del> <ins> AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </ins> 5.4.2.
Code change:
draft-ietf-quic-tls currently mentions AEADAES256CCM, however there is no way to use that AEAD in TLS 1.3 - TLSAES256CCMSHA256 does not appear in the . If I understand this correctly, the presence of AEADAES256CCM in the document was an editorial oversight.
Thanks. This was extremely confusing: you meant CCM, but wrote GCM in tons of places.

Related discussion:
text: 5.4.3. This section defines the packet protection algorithm for <del> AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and AEAD_AES_256_CCM.  AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES AES in electronic code-book (ECB) mode.  AEAD_AES_256_GCM, and AEAD_AES_256_CCM use 256-bit AES in ECB mode. </del> <ins> AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES AES in electronic code-book (ECB) mode.  AEAD_AES_256_GCM uses 256-bit AES in ECB mode. </ins> This algorithm samples 16 bytes from the packet ciphertext.  This value is used as the input to AES-ECB.  In pseudocode:
Code change:
I must have missed this when making the PR to remove the version negotiation text. Thanks NAME !
I wasn’t aware that there was an issue. Sorry for that!
No worries, thanks for doing this!
We can probably remove big chunks of section "8.1. Protocol and Version Negotiation" since we don't do version negotiation anymore in v1.
Fixed with . Thanks NAME

Related discussion:
text: 8.1. <del> The QUIC version negotiation mechanism is used to negotiate the version of QUIC that is used prior to the completion of the handshake.  However, this packet is not authenticated, enabling an active attacker to force a version downgrade. To ensure that a QUIC version downgrade is not forced by an attacker, version information is copied into the TLS handshake, which provides integrity protection for the QUIC negotiation.  This does not prevent version downgrade prior to the completion of the handshake, though it means that a downgrade causes a handshake failure. </del> QUIC requires that the cryptographic handshake provide authenticated protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) RFC7301 to select an application protocol.  Unless
Code change:
This just writes down what was proposed in .
Looks fine, but what about some guidance on stream vs connection errors? And also the principle of nearly always choosing a hard protocol violation error, or a more granular error with same effect?
Stream vs. connection is something that application protocols (like HTTP) need to worry about. The transport only concerns itself with connection errors. The idea that you pick the most helpful error is not something that we need to codify (in my view).
Isn't that worth mentioning? Or do we already have such text?
This is already discussed in Section 11, which makes me wonder if it would make more sense for text on this PR to be placed there too.
This I do not disagree with. I was merely suggesting that we explain why, as a general rule, a hard error is preferred as a design principle, not the nature of the error message which I do think should have a large degree of freedom.
Maybe there is a followup needed for the HTTP draft. If the principles are generally the same, we can copy the text and then add some more to cover the idea that we make most errors fatal to the connection rather than the stream.
I like Lucas suggestion of adding this text to the existing and already fairly complete text in section 11.
I moved the second paragraph up to the error handling section, but the text about how codes are selected really belongs with the codes themselves.
We don't really have any real principles that we agree on for deciding what error codes we are describing. Proposal: if the error carries distinct semantics (like stream rejection in HTTP), then it gets a new error code if the error is frequent or particularly significant, then it gets a new error code otherwise, target a more generic error code that identifies the broad area of the protocol finally, if there is no more specific applicable error code, use PROTOCOL_VIOLATION
is example of an issue discussed where it would have been useful to have principles.

Related discussion:
text: The most appropriate error code (error-codes) SHOULD be included in the frame that signals the error.  Where this specification identifies error conditions, it also identifies the error code that <del> is used. </del> <ins> is used; though these are worded as requirements, different implementation strategies might lead to different errors being reported.  In particular, an endpoint MAY use any applicable error code when it detects an error condition; a generic error code (such as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place of specific error codes. </ins> A stateless reset (stateless-reset) is not suitable for any error that can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame.
Code change:
This just writes down what was proposed in .
Looks fine, but what about some guidance on stream vs connection errors? And also the principle of nearly always choosing a hard protocol violation error, or a more granular error with same effect?
Stream vs. connection is something that application protocols (like HTTP) need to worry about. The transport only concerns itself with connection errors. The idea that you pick the most helpful error is not something that we need to codify (in my view).
Isn't that worth mentioning? Or do we already have such text?
This is already discussed in Section 11, which makes me wonder if it would make more sense for text on this PR to be placed there too.
This I do not disagree with. I was merely suggesting that we explain why, as a general rule, a hard error is preferred as a design principle, not the nature of the error message which I do think should have a large degree of freedom.
Maybe there is a followup needed for the HTTP draft. If the principles are generally the same, we can copy the text and then add some more to cover the idea that we make most errors fatal to the connection rather than the stream.
I like Lucas suggestion of adding this text to the existing and already fairly complete text in section 11.
I moved the second paragraph up to the error handling section, but the text about how codes are selected really belongs with the codes themselves.
We don't really have any real principles that we agree on for deciding what error codes we are describing. Proposal: if the error carries distinct semantics (like stream rejection in HTTP), then it gets a new error code if the error is frequent or particularly significant, then it gets a new error code otherwise, target a more generic error code that identifies the broad area of the protocol finally, if there is no more specific applicable error code, use PROTOCOL_VIOLATION
is example of an issue discussed where it would have been useful to have principles.

Related discussion:
text: See iana-error-codes for details of registering new error codes. <ins> In defining these error codes, several principles are applied.  Error conditions that might require specific action on the part of a recipient are given unique codes.  Errors that represent common conditions are given specific codes.  Absent either of these conditions, error codes are used to identify a general function of the stack, like flow control or transport parameter handling. Finally, generic errors are provided for conditions where implementations are unable or unwilling to use more specific codes. </ins> 20.1. Application protocol error codes are 62-bit unsigned integers, but
Code change:
As discussed, this is a) hard to do in all cases, b) impossible to do in many, and c) not that useful.
good
When multiple connections share the same network path or multiple connection IDs are used for the same path, using the spin bit is complicated by the difficulty in correlating forward and reverse flows. There is currently text that uses RFC 6919 language in the draft recommending coordination of the spin to avoid this problem. However, as , this coordination seems difficult and therefore unlikely. It also creates a strong signal that indicates that all the connections on the path are terminated at the same endpoint on both ends. Maybe we don't want to be generating that signal. Also, because this coordination can't be guaranteed, the on-path observer is forced to build code for correlating/segregating measurements by connection ID in the case where there is no coordination. Maybe it's best just to remove this recommendation entirely.
+1 to removing the recommendation, or changing the statement to just a caution (e.g., if you are to coalesce connections that spin, then you'd better be aware of ...). FWIW I am not sure if I agree with this observation. IIUC, the connections sharing a 5-tuple will be terminated by the same endpoint on both ends; it is impossible for a middlebox to coalesce multiple QUIC connections. It is impossible because CIDs can change mid-connection, and a middlebox cannot determine to where the packets containing the new CID must be sent.
There definitely needs to be a degree of coordination between the middlebox and the endpoints, but that doesn't mean that you can't use something like the quic-lb stuff on either end (or both ends).
Yes, I think it is better to remove that recommendation, but perhaps replace it with a note to observers.

Related discussion:
text: process performed at the beginning of the connection SHOULD be applied for all paths used by the connection. <del> In case multiple connections share the same network path, as determined by having the same source and destination IP address and UDP ports, endpoints should try to co-ordinate across all connections to ensure a clear signal to any on-path measurement points. </del> When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that endpoints set the spin bit to a random value either chosen
Code change:
Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.

Related discussion:
text: Indicates that x is A bits long Indicates that x uses the prefixed integer encoding defined in <del> Section 5.1 of RFC7541, beginning with an A-bit prefix. </del> <ins> prefixed-integers, beginning with an A-bit prefix. </ins> Indicates that x is variable-length and extends to the end of the region.
Code change:
Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.

Related discussion:
text: An encoder informs the decoder of a change to the dynamic table capacity using an instruction which begins with the '001' three-bit <del> pattern.  The new dynamic table capacity is represented as an integer with a 5-bit prefix (see Section 5.1 of RFC7541). </del> <ins> pattern.  This is followed by the new dynamic table capacity represented as an integer with a 5-bit prefix (see prefixed- integers). </ins> The new capacity MUST be lower than or equal to the limit described in maximum-dynamic-table-capacity.  In HTTP/3, this limit is the
Code change:
Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.

Related discussion:
text: or the dynamic table using an instruction that starts with the '1' one-bit pattern.  The second ("S") bit indicates whether the reference is to the static or dynamic table.  The 6-bit prefix <del> integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. </del> <ins> integer (see prefixed-integers) that follows is used to locate the table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. </ins> The header name reference is followed by the header field value <del> represented as a string literal (see Section 5.2 of RFC7541). </del> <ins> represented as a string literal (see string-literals). </ins> 4.3.3. An encoder adds an entry to the dynamic table where both the header field name and the header field value are represented as string <del> literals (see primitives) using an instruction that starts with the '01' two-bit pattern. </del> <ins> literals using an instruction that starts with the '01' two-bit pattern. </ins> <del> The name is represented as a 6-bit prefix string literal, while the value is represented as an 8-bit prefix string literal. </del> <ins> This is followed by the name represented as a 6-bit prefix string literal, and the value represented as an 8-bit prefix string literal (see string-literals). </ins> 4.3.4. An encoder duplicates an existing entry in the dynamic table using an <del> instruction that starts with the '000' three-bit pattern.  The relative index of the existing entry is represented as an integer with a 5-bit prefix. </del> <ins> instruction that begins with the '000' three-bit pattern.  This is followed by the relative index of the existing entry represented as an integer with a 5-bit prefix (see prefixed-integers. </ins> The existing entry is re-inserted into the dynamic table without resending either the name or the value.  This is useful to mitigate
Code change:
Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.

Related discussion:
text: After processing a header block whose declared Required Insert Count is not zero, the decoder emits a Header Acknowledgement instruction. <del> The instruction begins with the '1' one-bit pattern and includes the header block's associated stream ID, encoded as a 7-bit prefix integer.  It is used by the peer's encoder to know when it is safe to evict an entry (blocked-insertion), and possibly update the Known Received Count (known-received-count). </del> <ins> The instruction begins with the '1' one-bit pattern which is followed by the header block's associated stream ID encoded as a 7-bit prefix integer (see prefixed-integers). This instruction is used as described in known-received-count and in state-synchronization. </ins> If an encoder receives a Header Acknowledgement instruction referring to a stream on which every header block with a non-zero Required
Code change:
Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.

Related discussion:
text: When a stream is reset or reading is abandoned, the decoder emits a Stream Cancellation instruction.  The instruction begins with the <del> '01' two-bit pattern.  The instruction includes the stream ID of the affected stream encoded as a 6-bit prefix integer.  See state- synchronization. </del> <ins> '01' two-bit pattern, which is followed by the stream ID of the affected stream encoded as a 6-bit prefix integer. This instruction is used as described in state-synchronization. </ins> 4.4.3. The Insert Count Increment instruction begins with the '00' two-bit <del> pattern.  The instruction specifies the total number of dynamic table inserts and duplications since the last Insert Count Increment or Header Acknowledgement that increased the Known Received Count for the dynamic table (see known-received-count).  The Increment field is encoded as a 6-bit prefix integer.  The encoder uses this value to determine which table entries might cause a stream to become blocked, as described in state-synchronization. </del> <ins> pattern, followed by the Increment encoded as a 6-bit prefix integer. The value of the Increment is the total number of dynamic table insertions and duplications processed by the decoder since the last time it sent a Header Acknowledgement instruction that increased the Known Received Count (see known-received-count) or an Insert Count Increment instruction.  The encoder uses this value to update the Known Received Count, as described in state-synchronization. </ins> An encoder that receives an Increment field equal to zero or one that increases the Known Received Count beyond what the encoder has sent
Code change:
Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.

Related discussion:
text: 4.5. <del> Header blocks contain compressed representations of header lists and are carried in frames on streams defined by the enclosing protocol. These representations reference the static table, or dynamic table in a particular state without modifying it. </del> <ins> A header block consists of a prefix and a possibly empty sequence of representations defined in this section.  Each representation corresponds to a single header field.  These representations reference the static table or the dynamic table in a particular state, but do not modify that state. Header blocks are carried in frames on streams defined by the enclosing protocol. </ins> 4.5.1.
Code change:
Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.

Related discussion:
text: absolute index less than the Base, this representation starts with the '1' 1-bit pattern, followed by the "S" bit indicating whether the reference is into the static or dynamic table.  The 6-bit prefix <del> integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents </del> <ins> integer (see prefixed-integers) that follows is used to locate the table entry for the header field.  When S=1, the number represents </ins> the static table index; when S=0, the number is the relative index of the entry in the dynamic table.
Code change:
Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.

Related discussion:
text: than or equal to the Base, the representation starts with the '0001' 4-bit pattern, followed by the post-base index (see post-base) of the matching header field, represented as an integer with a 4-bit prefix <del> (see Section 5.1 of RFC7541). </del> <ins> (see prefixed-integers). </ins> 4.5.4.