jiebi/CodeConvo huggingface dataset:
Change:
much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. <ins> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support the intended application layer protocol. </ins> 4. This document specifies two means of performing version negotiation:

Discussion:
Two versions might be compatible in the sense that one can convert the Initial Packet from one into the other. But one version might not have the features necessary for an application. There are two ways to mediate this that I can see: 1) The client excludes compatible versions that are inadequate for the app from its TP. This means the QUIC API will need a way for applications to control the advertised versions. 2) Servers understand what capabilities are needed and will not select an advertised compatible version that does not support them. For incompatible VN, if the server can identify the application based on IP and port, it might scrub irrelevant versions from its VN packet, though I don't know if that's a good idea or not.
When MsQuic implemented this extension, we exposed a configuration option to the app for it to specify its "desired version list". My expectation is that a client would include all acceptable QUIC versions here, and then adapt (if necessary) their protocol layer accordingly. Though, this might get harry, for instance, if they need to then choose a different ALPN based on the negotiated QUIC version (we don't currently support that).
NAME you're describing an implicit assumption of the draft: the list of supported versions are specific to an application, not just to an implementation. Perhaps we can add a sentence to make that more obvious, such as Servers don't need to do anything here, it's the client's responsibility to know what it wants to do with a given connection, not the server's.
Yes NAME that works for me. The real issue is that this not totally internal to the QUIC implementation and there needs to be an API for the application to manage this.
I agree that such an API is reasonable (Google QUICHE provides one for example) but I think that's out of scope for this document though.
I agree you shouldn't define the API, but it would be good to say, "hey, dummy, don't just advertise every compatible version the QUIC implementation supports"
Note that the relationship between version selection and ALPN is similar to the aftereffects of HTTP/2, which made the cipher selection and ALPN selection within TLS interdependent. That was a pain. It doesn't affect this draft per se, but I do hope we don't paint ourselves into that particular corner again.
Change:
non-existing resource. A hypermedia control that enables a client to navigate between <del> resources and thereby change the application state. </del> <ins> resources and thereby change the client state. </ins> A string such as "text/html" or "application/json" that is used to label representations so that it is known how the representation

Discussion:
Addressing issue
Thanks Ari :) I will do a final pass and merge.
Originally, application state defined the state kept on the client, that is, what Web page is currently rendered and which pages were visited before. This does not make sense anymore when resource state is more than static Web pages, but parameters, physical state, etc. "Application state" logically would mean the state of the overall IoT application (state of the client and resoource state).
Related comment by Mike Amundsen:
I would add a comment in the definition, that this is called "Application State" in Fielding's thesis, but has some ambiguity in mordern (IoT) applications, where resource state is very dynamic and reflects part of the state in which the overall application is.
Change:
TCP, this may correspond to when the data has entered the send buffer. <ins> 5.1.1.3. Since sending a Message may involve a context switch between the application and the transport system, sending patterns that involve multiple small Messages can incur high overhead if each needs to be enqueued separately.  To avoid this, the application should have a way to indicate a batch of Send actions, during which time the implementation will hold off on processing Messages until the batch is complete.  This can also help context switches when enqueuing data in the interface driver if the operation can be batched. </ins> 5.1.2. Similar to sending, Receiving a Message is determined by the top-

Discussion:
See issue The one question I have here is the semantics around batching. In our implementation, we use block semantics (from clang), to batch looks like: connectionbatch(^{ connectionsend(...); connection_send(...); }); where the block is called inline, and the batch is over when the block returns. I'm not sure what the right style for the pseudo-code is for the draft.
In aligning the implementation with the API for the initial draft, we removed this text since we still need text in the API: Since sending a Message may involve a context switch between the application and the transport system, sending patterns that involve multiple small Messages can incur high overhead if each needs to be enqueued separately. To avoid this, the application should have a way to indicate a batch of Send actions, during which time the implementation will hold off on processing Messages until the batch is complete. This can also help context switches when enqueuing data in the interface driver if the operation can be batched.
This seems equivalent to the idea of PUSH in existing systems and would make sense for lots of short write calls.
+1. The higher-level question here is how to support high-performance applications. Send batching is one thing you can do here. Receive batching would be another obvious one. Zero-copy is another, though that's probably so tied to implementation and platform that it's not useful to standardize. But there should be some way for this interface to coexist with it...
+1 from me too
+1 In my opinion, support for high-performance applications is nothing we can add to the API, but rather something we must sure to not prevent or make hard to implement. So we should ask ourselves for every point in the API "can this be implemented zero-copy" or "can an implementation batch this" – if the answer is no, we have to fix that.
this one seems to have consensus and does not seem to be too much work. NAME if you can get a PR in in the next week or so let's ship it with ietf-00...
I'll try to get this in soon!
fixed with merge of
LGTM, we can worry about the right way to pseudocode this later.
Change:
The context ID to close. <del> A string of comma-separated key-value pairs to enable extensibility, see the definition of the same field in register- capsule for details. </del> <ins> See context-ext. </ins> Note that this close is unilateral and bidirectional: the sender of the frame unilaterally informs its peer of the closure.  Endpoints

Discussion:
This PR adds a new concept of context close codes which will allow applications that use contexts to indicate the reason for closing a context. This PR also makes the extensibility mechanism binary as that is easier to implement.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
LGTM thanks
Change:
generally, this is one higher than the offset of the byte with the largest offset sent on the stream, or zero if no bytes were sent. <del> For a stream that is reset, the final size is carried explicitly in a RESET_STREAM frame.  Otherwise, the final size is the offset plus the length of a STREAM frame marked with a FIN flag, or 0 in the case of incoming unidirectional streams. </del> <ins> The final size of a stream is always signaled to the recipient.  The final size is the sum of the Offset and Length fields of a STREAM frame with a FIN flag, noting that these fields might be implicit. Alternatively, the Final Size field of a RESET_STREAM frame carries this value.  This ensures that all ways that a stream can be closed result in the number of bytes on the stream being reliably transmitted.  This guarantees that both endpoints agree on how much flow control credit was consumed by the stream. </ins> An endpoint will know the final size for a stream when the receiving part of the stream enters the "Size Known" or "Reset Recvd" state

Discussion:
Section: Stream Final Size /An endpoint MUST NOT send data on a stream at or beyond the final size./ It seems reasonable not to send after the Final Size , but why is this a “MUST NOT”? The need to require this is not stated, and the reaction of the receiver appears to be ignore. Is this requirement justified?
Because the Final Size is used to synchronize flow control consumption. If the Final Size is not, in fact, the last data ever sent on a stream, the two sides will disagree about how much flow control credit has been consumed. The reaction of the receiver isn't to ignore; in the very next paragraph:
Aha, I knew there must be a reason - could we add something like this sentence? "This is used to synchronize flow control consumption between the endpoints."
:+1: LGTM modulo a nitpick.Some suggestions
Change:
to transfer to a new network path. Frames are used in QUIC to communicate between endpoints.  One or <del> more frames are assembled into packets.  QUIC authenticates all </del> <ins> more frames are assembled into a QUIC packet.  QUIC authenticates all </ins> packets and encrypts as much as is practical.  QUIC packets are carried in UDP datagrams (UDP) to better facilitate deployment in existing systems and networks.

Discussion:
Error? / A stateless reset is not appropriate for signaling error conditions./ I understand, but this sentence seems odd to me, is it possible to say /error conditions when there is connection state/ or something like that? Is it worth a cross ref to section 11 to be clear what a “normal” error is? Section 9 NiTs in wording: /Acknowledgments cannot be used for path validation as they contain insufficient entropy/ Acknowledgments cannot be used for path validation because they contain insufficient entropy/ /as endpoints independently determine reachability on each direction of a path./the endpoints independently determine reachability on each direction of a path./ Is it slightly easier to read: / One or more frames are assembled into packets./ / One or more frames are assembled into a QUIC packet./ In section 3.3. It says: /The receiver of a stream sends MAXSTREAMDATA (Section 19.10) and STOP_SENDING frames (Section 19.5)./ Is this a para where ACK frames should also be mentioned? It seemed odd to me that ACKs are not mentioned at some pointy around here.
I think that the intent is to be more general than just "this is not for connection errors". How about: I don't think that we want to talk about acknowledgements at the level of the stream section. They don't affect stream states and this is specifically about what stream-related frames can be sent.
Change:
Manage the removal of paths that have been abandoned. As such this extension specifies a departure from the specification <del> of path management in section 9 of QUIC-TRANSPORT and therefore </del> <ins> of path management in Section 9 of QUIC-TRANSPORT and therefore </ins> requires negotiation between the two endpoints using a new transport parameter, as specified in nego.

Discussion:
Fix issue
I went ahead and replaced the references to RFC9000 by QUIC-TRANSPORT, and RFC9001 by QUIC-TLS. I have checked that this produced the expected XML V3.
RFC9000 is cited massively in the draft. It would be helpful to indicate to the reader where to look by indicating the section. Some change examples are provided below: and so on.
Side comment -- please see issue about the use of XML2RFC v3 syntax for links. We can do some of that, but not necessarily everywhere. We do expect that readers are familiar with QUIC V1. If we want to say "we are just in line with QUIC V1", then a global reference to RFC 9000 should suffice. If we want to say "please read this text in QUIC V1, we don't want to replicate here", then yes, we should refer to the specific section.
Thanks, Christian. That's the intent.
The draft is using old style references, such as "section 9 of {{RFC9000}}". Version 3 of XML2RFC defines a structure way to do that, such as: , which can be expressed in recent versions of Markdown as . The new style references don't change the text version much, but in the HTML rendering they generate direct references to the target section, which is nice for the readers.
Sorry, that's my fault because of my local build system. Will fix this for the next revision...
With the fixed references, it works now...
Change:
The C bit (0x10) is set if the Connection ID is present. The S bit (0x08) indicates the size of the sequence number.  0 <del> means an 8-bit sequence number, 1 means 16-bit. </del> <ins> means an 8-bit sequence number, 1 means 16-bit.  Implementations MAY mix sequence numbers of different lengths on the same connection. </ins> The L bit (0x04) is set if the length is present.

Discussion:
Andy Cunningham wrote Text would not hurt in the draft to explain this.
Chairs, please opine on whether this should get confirmed on the list.
Change:
[[ See issue #105 [78] ]] <del> When used to bind to an access token, the </del> <ins> When used to bind to an access token, the access token MUST be covered by the signature method. </ins> 8.1.

Discussion:
This fixes up a dangling statement from the design team draft that somehow never got completed. It's technically a new normative statement but it was clearly intended by the context so this is not a functional or substantive change. Other changes are small formatting issues.
Change:
stream, HTTP/3 does not make use of this feature. QUIC streams can be either unidirectional, carrying data only from <del> initiator to receiver, or bidirectional.  Streams can be initiated by either the client or the server.  For more detail on QUIC streams, see Section 2 of QUIC-TRANSPORT. </del> <ins> initiator to receiver, or bidirectional, carrying data in both directions.  Streams can be initiated by either the client or the server.  For more detail on QUIC streams, see Section 2 of QUIC- TRANSPORT. </ins> When HTTP fields and data are sent over QUIC, the QUIC layer handles most of the stream management.  HTTP does not need to do any separate

Discussion:
This PR covers questions asked during Auth48 which aren't pure copyediting, but seem to have a straightforward single-location fix. Individual commits, so it's easy to pull one out if someone disagrees.
In , the RFC Editor asks:
Either A or B is better, but I have no preference.
Fixed in , but GitHub won't automatically close until it hits .
Change:
solutions that could quickly reach large scale deployments. Replacing clear text SNI transmission by an encrypted variant will <del> also thwart MITM interferences that are sometimes described as legitimate.  As explained in end-to-end, alternative solutions will have to be developed. </del> <ins> break or reduce the efficacy of the operational practices and techniques implemented in middle-boxes as described in snileak.  As explained in end-to-end, alternative solutions will have to be developed. </ins> 6.

Discussion:
Trying to address the last comments (issue ).
NAME I hope this reflects our discussion.
Checking in after Roman's comments on the list.
Change:
{TBD} 0xC5 {TBD} 0xE4 <del> Finally, this document reserves all ALPN identifiers RFC7301 beginning with the prefix "ignore/".  This corresponds to the seven- octet prefix: 0x69, 0x67, 0x6e, 0x6f, 0x72, 0x65, 0x2f. </del> 3. Most extension points in TLS are offered by the client and selected

Discussion:
Also fix the build. Some references were a little off.
A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users.
Ah yes, good point. That should be pointed out explicitly. Will put together a PR after Thanksgiving (and after is merged since it contains a build fix and I'm not sure how PRs depending on pieces of other PRs works :-) ).
NAME NAME NAME unless there are any objections once we get this issue squared away I'll go ahead and issue a WGLC. It's been marinating long enough.
Should be fixed by .
THere's a TODO for reserving "ignore/" ALPN.
NAME are you thinking: Protocol: ignore/1 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 Reference: (This document) ... Protocol: ignore/10 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 0x30 Reference: (This document)
I didn't have a particularly clear picture in my mind, TBH. We're not sending fake ALPN values or anything right now. ignore/[numbers] seems fine. Or maybe it would be better to drop the "ignore/" thing and just use the same two-byte pattern. "ignore/" makes it look like you should do a prefix check, which isn't really what we want...
NAME NAME NAME NAME NAME NAME PTAL because I think this is really the last "technical" point remaining.
NAME not sure what you mean by two-byte pattern. You mean things like "qz" "db" "r$" etc? If so, I agree that that is better.
Yeah. For the sake of consistency, I figure it could just be the same old 0x?a, 0x?a pattern that everything else does. (Though they then wouldn't be ASCII. Could pick some pattern that's ASCII if that's preferred.)
i think two random bytes is good (testing for non-ascii seems greasy as well)
I also prefer the two-byte pattern, since ignore/ might indicate to people that this is somehow meant to be special-cased.
Two bytes it is! URL
Change:
balancers that forward the traffic based on the Connection ID.  A server can choose the Connection ID in the Server Retry packet such that the load balancer will redirect the next Client Initial packet <del> to a different server in that pool. </del> <ins> to a different server in that pool.  Alternatively the load balancer can directly offer a Retry services as further described in QUIC-LB. RFC5077 Section 4 describes an example approach for constructing TLS resumption tickets that can be also applied for validation tokens, however, the use of more modern cryptographic algorithms is highly recommended. </ins> 10.

Discussion:
References to quic-load-balancers and RFC5077 (due to lack of a better reference) added
I thought the plan was to have a dependency on the load balancing draft rather than merging this part into the applicability draft. However, I would also be fine to add more text here and only have an informational reference, if some is willing to provide text!
... in the applicability statement? I mean one example mechanism maybe...
Can anybody help with that?
URL
The 5077 construction is pretty outdated (it's not even AEAD), unfortunately.
NAME is there somewhere else we should look for current best practice, or do we need to invent something new here?
I'll find a stuckee for up-to-date crypto language here at the Zurich interim.
closing for now, couldn't find any takers.
...actually, it's in the LB draft. Reference it.
PR proposed to address this issue...
Are you prepared to take a dependency on QUIC-LB?
Change:
certificate_request_context. This property makes it difficult to formally prove that a server <del> is jointly authoritative over multiple certificates, rather than </del> <ins> is jointly authoritative over multiple identities, rather than </ins> individually authoritative over each. There is no indication in the TLS layer about which point in time

Discussion:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME
Change:
credential in a ratchet tree, the KeyPackage ciphersuite for a credential in a KeyPackage object. <ins> For X509Credential, each entry in the chain represents a single DER- encoded X509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate and each subsequent certificate in the chain MUST be the issuer of the previous certificate.  The algorithm for the "public_key" in the end-entity certificate MUST match the relevant ciphersuite. </ins> For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified RFC8032.  For ciphersuites using ECDSA with the NIST curves P-256 or P-521, the public key is the output of

Discussion:
This PR adds clarification around X509 cert structure, the chain and its encoding X509.
NAME thanks for the suggestions. updated PR to reflect the changes . pls let me know ..
NAME i have pushed another commit .. can you please check. thanks
Change:
CurveCP <del> ESP </del> <ins> IKEv2 </ins> WireGuard

Discussion:
Address . IKE has mobility via MOBIKE (which makes ESP move, but it's more a property of IKE)
Yes, my impression was that we would keep the lists as well as the table?
Comment from Ekr's review of -10: o Mobility Events: The record protocol can be signaled that it is being migrated to another transport or interface due to connection mobility, which may reset address and state validation and induce state changes such as use of a new Connection Identifier (CID). How does this work in ESP, actually? DTLS sort of has this, in that it has a CID, but vague migration rules.
It may be better to mark this as IKEv2/ESP; it's MOBIKE that supports mobility.
This can be closed now, right?
Yup!
Interesting - so we do differentiate between ESP and IKEv2 here? (In Section 3.4.1 we say that "this document considers them together, since that is the most common pattern".) I'm okay with this and I've adjusted the summary table, which now has ESP and IKEv2 separately, in the other PR. As I'm not sure we want to put a reference into the summary table, I guess this means that we're keeping the protocol lists in addition to the summary table, which I'm also fine with.