jiebi/CodeConvo huggingface dataset:
Change:
Is it worth adding a reference to RFC 8441? That's an alternative that covers what people looking for this functionality were probably trying to do.
That's a good point, let me craft something up and I'll update the PR soon.
Ping NAME unless you'd like me to take it over.
I'll get an update out tomorrow
I'm actually not convinced that referencing 8441 will help clarify things here because the extension is H2 specific. No H3-equivalent exists (or at least, no H3 setting to enable the equivalent CONNECT behaviour exists).
I agree. I think referencing 8441 might just add to the confusion - even if something like 8441 certainly can be introduced.
Some others have shown interest for defining/framing this capability in HTTP/3. I think that activity should consider ore broadly what text makes sense in the core document.
Fair enough. Let's merge the rebased version, then, and leave the right way to do this for an H3 extension.
HTTP/3 makes no explicit comment about this. HTTP/2 prohibits it. So I think that we might want to add equivalent text. URL informational status code ([RFC7231], Section 6.2.2). multiplexed protocol.

Discussion:
4.3. <ins> HTTP/3 does not support the HTTP Upgrade mechanism (RFC7230, Section 6.7) or 101 (Switching Protocols) informational status code (RFC7231, Section 6.2.2). 4.4. </ins> Server push is an interaction mode introduced in HTTP/2 HTTP2 which permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request.  This trades
Change:
Now that the PTO retransmits Initial and Handshake data, it's possible and likely desirable to bundle multiple QUIC packets in a single datagram. This change makes it clear that is allowed.
nits, but lgtm

Discussion:
6.2. <del> A Probe Timeout (PTO) triggers sending one or two probe packets when ack-eliciting packets are not acknowledged within the expected period of time or the handshake has not been completed.  A PTO enables a connection to recover from loss of tail packets or acks.  The PTO algorithm used in QUIC implements the reliability functions of Tail Loss Probe TLP RACK, RTO RFC5681 and F-RTO algorithms for TCP RFC5682, and the timeout computation is based on TCP's retransmission timeout period RFC6298. </del> <ins> A Probe Timeout (PTO) triggers sending one or two probe datagrams when ack-eliciting packets are not acknowledged within the expected period of time or the handshake has not been completed.  A PTO enables a connection to recover from loss of tail packets or acknowledgements.  The PTO algorithm used in QUIC implements the reliability functions of Tail Loss Probe TLP RACK, RTO RFC5681 and F-RTO algorithms for TCP RFC5682, and the timeout computation is based on TCP's retransmission timeout period RFC6298. </ins> 6.2.1.

When a PTO timer expires, a sender MUST send at least one ack- eliciting packet as a probe, unless there is no data available to <del> send.  An endpoint MAY send up to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single packet loss. </del> <ins> send.  An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram. </ins> It is possible that the sender has no new or previously-sent data to send.  As an example, consider the following sequence of events: new
Change:
The TPs might carry a stateless reset token, which must be encrypted in transit. Section 7 in the transport document [1] lists some requirements for the handshake, including authentication of the TPs, yet does not include any mention of encrypting them from server to client. Should it? cc NAME NAME [1] URL
This makes sense to me. The TLS document ensures that the server's transport parameters are encrypted so an editorial PR changing the transport doc to require that should be sufficient.
Good catch. Marking as design so that we can consensus call this, but it's arguably editorial.

Discussion:
1-RTT keys have forward secrecy <del> authenticated values for the transport parameters of the peer (see transport-parameters) </del> <ins> authenticated values for transport parameters of both endpoints, and confidentiality protection for server transport parameters (see transport-parameters) </ins> authenticated negotiation of an application protocol (TLS uses ALPN RFC7301 for this purpose)
Change:
S 5.1. says At minimum this needs to be restricted to endpoints and other elements associated with them (like load balancers) because they need to be able to correlate connection IDs. But this is also a very strong condition, and in some cases will basically mandate encryption.
It should contain "by an external observer". I believe there is other text mentioning coordination with load balancers when constructing CID's. It is a strong condition - without it all other work on preventing linkage is more or less useless.
It feels strange to me that this is an RFC8174 MUST NOT, as it's unclear how to enforce it. That said, I agree that this text should be constrained to external observers - and clearly define who that is.
Maybe change to “Connection IDs MUST NOT expose”?
Tokyo conclusion: describe what the attack is and explain that anti-correlation text exists as an answer to this. The normative language is perhaps too strong, given that it might be possible to create smaller anonymity sets and still have a reasonable answer to the attack.
Discussed in London, NAME to resume work
NAME how is this progressing?
I believe this is an editorial issue, not design. We all know what we mean: it can encode information by use for itself and trusted intermediaries, but definitely is not correlatable. I agree that MUST is a little tricky unless we are mandating either true encryption or true randomness, which is a discussion I was hoping to defer until QUIC-LB is adopted.
Looks fine. This paragraph is wrapped to a shorter line-length than the standard for the document.

Discussion:
by the endpoint upon receipt. Connection IDs MUST NOT contain any information that can be used by <del> an external observer to correlate them with other connection IDs for the same connection.  As a trivial example, this means the same connection ID MUST NOT be issued more than once on the same connection. </del> <ins> an external observer (that is, one that does not cooperate with the issuer) to correlate them with other connection IDs for the same connection.  As a trivial example, this means the same connection ID MUST NOT be issued more than once on the same connection. </ins> Packets with long headers include Source Connection ID and Destination Connection ID fields.  These fields are used to set the
Change:
Emphasize that SETTINGSQPACKBLOCKED_STREAMS is set by the decoder. Move normative sentence on decoder encountering excessive number of blocked streams to this paragraph. Split note to separate paragraph.
:+1: This reads much better to me.

Discussion:
greater than its own Insert Count, the stream cannot be processed immediately, and is considered "blocked" (see {blocked-decoding}). <del> The SETTINGS_QPACK_BLOCKED_STREAMS setting (see configuration) specifies an upper bound on the number of streams which can be blocked.  An encoder MUST limit the number of streams which could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all times.  Note that the decoder might not become blocked on every stream which risks becoming blocked. </del> <ins> The decoder specifies an upper bound on the number of streams which can be blocked using the SETTINGS_QPACK_BLOCKED_STREAMS setting (see configuration).  An encoder MUST limit the number of streams which could become blocked to the value of SETTINGS_QPACK_BLOCKED_STREAMS at all times.  If an decoder encounters more blocked streams than it promised to support, it MUST treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED. Note that the decoder might not become blocked on every stream which risks becoming blocked. </ins> An encoder can decide whether to risk having a stream become blocked. If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS,

it MAY treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED. <del> If the decoder encounters more blocked streams than it promised to support, it MUST treat this as a connection error of type HTTP_QPACK_DECOMPRESSION_FAILED. </del> 2.2.2. The decoder signals the following events by emitting decoder
Change:
The definition of a blocking entry has two parts: insertion not acknowledged, or not all references acknowledged. Update text in two places to include the part about acknowledging the insertion, lest a reader forget about it.

Discussion:
The Header Acknowledgement and Stream Cancellation instructions permit the encoder to remove references to entries in the dynamic <del> table.  When entries have zero references they are no longer considered blocking (see blocked-insertion). </del> <ins> table.  When an entry with absolute index lower than the Known Received Count has zero references, then it is no longer considered blocking (see blocked-insertion). </ins> 2.2.2.3.
Change:
Add MUST to sentence about requirement on decoder to emit a Header Acknowledgement instruction every time it decodes a header block with non-zero Required Insert Count.
That's a good point, I haven't thought about it. Would changing "When the decoder finishes decoding..." to "After the decoder finishes decoding..." be sufficient to allow for delayed ACKs?
Works for me.
Done. Thanks for raising this issue.
You can't coalesce Header Acks like you can Insert Count Increment or transport Acks. The only overhead savings comes from when these are sent to the peer - eg: transport overhead. The text only says the Ack, and doesn't really describe how quickly it has to be conveyed. But I don't really have a problem with when vs. after either.
This doesn't allow for a delay in sending an ack. That delay might be useful in reducing overheads. That might be a new issue though.

Discussion:
2.2.2.1. <del> When the decoder finishes decoding a header block containing dynamic </del> <ins> After the decoder finishes decoding a header block containing dynamic </ins> table references, it MUST emit a Header Acknowledgement instruction (header-acknowledgement).  A stream may carry multiple header blocks in the case of intermediate responses, trailers, and pushed requests.
Change:
Since post-base index has a section separate from relative index, I do not consider post-base index a type of relative index, but a distinct category. Update text accordingly. If the consensus is that this is not the case, relative index and post-base index sections should be reworded, and a new term should be introduced for non-post-base relative index.

Discussion:
A unique index for each entry in the dynamic table. <del> A reference point for relative indices.  Dynamic references are made relative to a Base in header blocks. </del> <ins> A reference point for relative and post-base indices.  References to dynamic table entries in header blocks are relative to a Base. </ins> The total number of entries inserted in the dynamic table.

For example, with a Required Insert Count of 9, a decoder receives a S bit of 1 and a Delta Base of 2.  This sets the Base to 6 and enables post-base indexing for three entries.  In this example, a <del> regular index of 1 refers to the 5th entry that was added to the </del> <ins> relative index of 1 refers to the 5th entry that was added to the </ins> table; a post-base index of 1 refers to the 8th entry. 4.5.2.
Change:
Mention that application data could be conveyed in other frame types than STREAM frames. (E.g. the proposed DATAGRAM draft sends application data in DATAGRAM frames.)
This was correct at the time, because only STREAM carried application semantics, but that's too constraining, even now. Thanks.

Discussion:
Unlike TLS over TCP, QUIC applications which want to send data do not send it through TLS "application_data" records.  Rather, they send it <del> as QUIC STREAM frames which are then carried in QUIC packets. </del> <ins> as QUIC STREAM frames or other frame types which are then carried in QUIC packets. </ins> 4.
Change:
I'm pretty sure this was obsoleted when version negotiation was removed (along with initial/negotiated/supported versions from transport parameters). If you think the TLS handshake is still validating protocol version selection, feel free to reject this PR.

Discussion:
8. QUIC uses the TLS handshake for more than just negotiation of <del> cryptographic parameters.  The TLS handshake validates protocol version selection, provides preliminary values for QUIC transport parameters, and allows a server to perform return routability checks on clients. </del> <ins> cryptographic parameters.  The TLS handshake provides preliminary values for QUIC transport parameters and allows a server to perform return routability checks on clients. </ins> 8.1.
Change:
Thanks! Beat me to it.
In quic-transport-22 section 19.6 it says CRYPTO frames can be sent in all packet types. However in quic-tls-22 section 4 it says the CRYPTO frames can't be sent in 0-RTT packets. Also in quic-tls-22 section 8.3, similar statement. Maybe the statement in quic-transport-22 needs to be corrected?

Discussion:
19.6. The CRYPTO frame (type=0x06) is used to transmit cryptographic <del> handshake messages.  It can be sent in all packet types.  The CRYPTO frame offers the cryptographic protocol an in-order stream of bytes. CRYPTO frames are functionally identical to STREAM frames, except that they do not bear a stream identifier; they are not flow </del> <ins> handshake messages.  It can be sent in all packet types except 0-RTT. The CRYPTO frame offers the cryptographic protocol an in-order stream of bytes.  CRYPTO frames are functionally identical to STREAM frames, except that they do not bear a stream identifier; they are not flow </ins> controlled; and they do not carry markers for optional offset, optional length, and the end of the stream.
Change:
Specify that ECN counts in the ACK frame to be in the same pn_space of the ACK frame. Change pseudocode in recovery-draft to reflect that.
This only changes pseudocode and no normative text, so I'm inclined to mark it editorial and merge it.
Are ECN counts in ACK frames per pnspace or unified across pnspaces? I've observed different behaviors of public servers regarding that. [13.3.1. ECN Counts] seems to suggest they are per pnspace: However, [19.3.2. ECN Counts] says: Pseudocode in the recovery draft (Appendix B. Congestion Control Pseudocode) also has a global ecnce_counter.
Thanks for the issue, NAME PR looks good.
Thanks! NAME want to take a look?

Discussion:
The three ECN Counts are: A variable-length integer representing the total number of packets <del> received with the ECT(0) codepoint. </del> <ins> received with the ECT(0) codepoint in the packet number space of the ACK frame. </ins> A variable-length integer representing the total number of packets <del> received with the ECT(1) codepoint. </del> <ins> received with the ECT(1) codepoint in the packet number space of the ACK frame. </ins> A variable-length integer representing the total number of packets <del> received with the CE codepoint. </del> <ins> received with the CE codepoint in the packet number space of the ACK frame. </ins> ECN counts are maintained separately for each packet number space.
Change:
The Stream Commitment Attack part was added in draft-ietf-quic-transport-03, when unidirectional streams were not used. In draft-ietf-quic-transport-08, streams were split into unidirectional and bidirectional, but this example of stream commitment attack was missed.
Thanks, NAME I've done some editorializing, and merging.

Discussion:
Normally, clients will open streams sequentially, as explained in stream-id.  However, when several streams are initiated at short <del> intervals, transmission error may cause STREAM DATA frames opening streams to be received out of sequence.  A receiver is obligated to open intervening streams if a higher-numbered stream ID is received. Thus, on a new connection, opening stream 2000001 opens 1 million streams, as required by the specification. </del> <ins> intervals, loss or reordering may cause STREAM frames that open streams to be received out of sequence.  On receiving a higher- numbered stream ID, a receiver is required to open all intervening streams of the same type (see stream-recv-states).  Thus, on a new connection, opening stream 4000000 opens 1 million and 1 client- initiated bidirectional streams. </ins> The number of active streams is limited by the initial_max_streams_bidi and initial_max_streams_uni transport
Change:
On receiving duplicate QPACK streams, the error should be HTTPSTREAMCREATION_ERROR which matches with control stream duplicates.
Technically should have a corresponding issue, but yes. Nice spot!

Discussion:
HTTP/3 endpoints contain a QPACK encoder and decoder.  Each endpoint MUST initiate at most one encoder stream and at most one decoder stream.  Receipt of a second instance of either stream type MUST be <del> treated as a connection error of type HTTP_WRONG_STREAM_COUNT.  These streams MUST NOT be closed.  Closure of either unidirectional stream type MUST be treated as a connection error of type </del> <ins> treated as a connection error of type HTTP_STREAM_CREATION_ERROR. These streams MUST NOT be closed.  Closure of either unidirectional stream type MUST be treated as a connection error of type </ins> HTTP_CLOSED_CRITICAL_STREAM. An endpoint MAY avoid creating its own encoder stream if it's not
Change:
Byte order of IP addresses in PreferredAddress is not explicitly stated. In practice, most OSs keep them in network byte order, and the spec says integers are in network byte order, however the fields for ip addresses are defined as opaque data. The byte order should be stated on this spec.

Discussion:
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 <del> family. </del> <ins> family.  IP addresses are encoded in network byte order. </ins> The maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes only connection
Change:
This doesn't add rationale. It doesn't have to. The rationale isn't high-minded, it's just motivated by a desire to complete this protocol.
Should the server just ignore it, or is is a protocol violation?
I vote for protocol violation.
The spec says nothing...
Yeah, there's no need to vote, this is just an omission. A protocol violation (or similar) is what we should mandate.
Playing devils' advocate: what about p2p apps? The token says, you can call me back from that address, I will accept it. The client is not saying anything untrue.
I'll bite. Yes, a P2P app that used mutual authentication in a way that would allow a former server to associate a token with an attempt to connect to a peer that was previously a client, might be able to use NEW_TOKEN. That's a little outside our remit. I'm going to take this as an editorial change on the understanding that a design issue could be opened to allow the asymmetry. Anyone who is serious about that should also consider the fact that NewSessionTicket in TLS is potentially symmetrical by the same logic. Which suggests that 0-RTT isn't out of the question either.
On p2p there is the potential problem of relating a token to previously stored settings and observables from a previous session. This isn't well defined if the client specifies a new token. So perhaps it is better for each peer to "waste" a single 1-RTT connection the first time in a given direction.

Discussion:
values, which might be used to link connection attempts; see validate-future. <ins> Clients MUST NOT send NEW_TOKEN frames.  Servers MUST treat receipt of a NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION. </ins> 19.8. STREAM frames implicitly create a stream and carry stream data.  The
Change:
They don't have a length field, so the only place they could go is at the end of a packet. As the spec currently stands, it's valid to send a packet like this. There's little value in doing that. Do we want to continue to allow this?
My understanding is that they are implicitly forbidden, because coalescing packets belonging to different connections are forbidden, and because there’s nothing to coalesce with when either of the two types of the packets is sent. I am not sure if we need to be more clear on that, considering the fact we generally use MAY for the discarding rules for coalesced packets.
VN certainly causes a new connection based on discussions in Tokyo. Retry does not cause a new connection(ie: same ClientHello). Clarifying this seems wise if it's not already clear.
Yes, however when a Retry packet is being sent, there's nothing a server can send along with. Regarding if we need to clarify, while I do not think it's absolutely necessary, I can see that people might want to have it stated considering the fact that we do utilize corner case rules of coalesced packets (see ).
So, is this editorial?
I'm with NAME but I'm still wondering: what is the clarification that we can provide?
NAME Simply clarifying that "VN and Retry packets will never be coalesced" as part of the changes we would make in might be a good idea. We do not need to use a RFC 2119 word here due to the editorial nature of the issue.

Discussion:
Retry packets (packet-retry), Version Negotiation packets (packet- version), and packets with a short header (short-header) do not contain a Length field and so cannot be followed by other packets in <del> the same UDP datagram. </del> <ins> the same UDP datagram.  Note also that there is no situation where a Retry or Version Negotiation packet is coalesced with another packet. </ins> 12.3.