jiebi/CodeConvo huggingface dataset:
Change:
evidence of reordering or packet loss and retransmit their final flight immediately, shortcutting the retransmission timer. <del> 5.6.2. </del> <ins> 5.7.2. </ins> Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems; for example, if

Discussion:
NAME
s'OK wi' me. The other thing to consider mentioning is that record shadowing (key compromise at epoch N allowing the attacker to send records that cause records at epoch >N to be dropped) isn't a concern because dropping records in DTLS is trivial.
NAME thoughts?
Change:
<del> The information carried in the access token in the form of type- value pairs is called parameters.  [FIXME: This gives the </del> <ins> Information carried in the access token, called claims, is in the form of type-value pairs.  [FIXME: This statement may give the </ins> impression that "parameter" is only used to describe the attributes in the access token and not in messages in general.] <del> An access token may for example include a parameter about the AS that issued the token (the "iss" parameter) and what audience the access token is intended for (the "aud" parameter).  The audience of an access token can be a specific resource or one or many resource servers.  The resource owner policies influence what parameters are put into the access token by the authorization server. </del> <ins> An access token may, for example, include a claim identifying the AS that issued the token (via the "iss" parameter) and what audience the access token is intended for (via the "aud" parameter).  The audience of an access token can be a specific resource or one or many resource servers.  The resource owner policies influence what claims are put into the access token by the authorization server. </ins> While the structure and encoding of the access token varies throughout deployments, a standardized format has been defined

Discussion:
I went through the overview section and updated the text. The text is already good and only a few minor changes had to be made. I believe we may need to determine (some time in the future) whether it is worthwhile to combine the introduction with the text in the overview section since there is some overlap.
I spotted a few sentences that were missing a word to make sense. I'll go through and try to fix this on Monday, unless someone else manages before me. Otherwise the changes look fine.
Change:
This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the <del> use of any Subject names in the certificate is restricted to use by a document signing service or a software (along with any usages allowed by other EKU values). </del> <ins> Subject named in the certificate signed the document content, and the associated keys can be used by a document signing service or a software for authentication, message integrity, and non-repudiation of origin (using digital signatures, along with any usages allowed by other EKU values). </ins> 4.

Discussion:
This PR contains corrections to more accurate expression. This PR does not contains modification related to backwards compatibility and interoperability.
Thanks Sean I approved all above modifications.
Change:
<https://www.iana.org/assignments/service-names-port-numbers/service- names-port-numbers.xhtml>. <del> IANA is requested to assign the System Port number 1001 and the service name "webpush" in accordance with RFC6335. </del> <ins> In accordance with RFC6335, it is requested that IANA assign the suggested System Port number 1001 (or another port in the System range) and the service name "webpush". </ins> webpush

Discussion:
Based on the IANA review: Update IANA Considerations to indicate the System Port 1001 is a suggestion Update inline references to 1001 to "TBD"
LGTM (I'll let you merge this one).
Change:
acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. On receiving an ACK_FREQUENCY frame and updating its recorded <del> "max_ack_delay" and "ACK-eliciting threshold" values (multiple- </del> <ins> "max_ack_delay" and "Ack-Eliciting Threshold" values (multiple- </ins> frames), the endpoint MUST send an acknowledgement when one of the following conditions are met: Since the last acknowledgement was sent, the number of received ack-eliciting packets is greater than or equal to the recorded <del> "ACK-eliciting threshold". </del> <ins> "Ack-Eliciting Threshold". </ins> Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed.

Discussion:
Part of We still need to decide whether to change 'Update Max Ack Delay' to 'Max Ack Delay'.
Change:
descriptions to the API, the API would produce and consume messages from this protocol.  While providing a more high-level API, this put more control of signaling within the JSEP implementation, forcing it <del> to have to understand and handle concepts like signaling glare.  In addition, it prevented the application from driving the state machine to a desired state, as is needed in the page reload case. </del> <ins> to have to understand and handle concepts like signaling glare (see RFC3264, Section 4). </ins> A second approach that was considered but not chosen was to decouple the management of the media control objects from session

Discussion:
NAME done. NAME still waiting for you.
Section 1.2 uses the term "glare" without describing it. This term may be unfamiliar to readers, and should be explained or cited.
Agreed.
See URL for a definition.
LGTM, but see comment
Change:
This section describes HTTP/3-specific error codes which can be used to express the cause of a connection or stream error. <del> 9.1. </del> <ins> 8.1. </ins> The following error codes are defined for use in QUIC RESET_STREAM frames, STOP_SENDING frames, and CONNECTION_CLOSE frames when using

Discussion:
no text changes outside the Document Organization section.
Wow, this is a fun diff to review :-)
That's why I pointed out that there are no actual text changes. But if it's easier, you could open and in side-by-side browser windows. :-) I'd like to land this fairly quickly; from some experiments, other HTTP PRs merge into this just fine if they come after, but risk being summarily wiped out if merged before it.
It's fine. The stream usage and request "lifecycle" sections are a bit too far apart, but I don't know that I have a suggestion there.
S 3.2.2. This isn't understandable without knowing what push is or what a PUSH promise is. Am I supposed to get that from 7540? In either case, you should clearly state that a push stream can only be used for a single push promise (this is implied by the formatting). Happy to supply a PR if we can agree on what's wanted?
Yes, as currently written, a push stream corresponds 1:1 with a PUSH_PROMISE. Which is consistent again with 7540 (we had a period where it was not).
Well. A push stream corresponds one-to-one with a push ID. You can duplicate promises using the DUPLICATE_PUSH frame. I think this is what was attempted to be described by the term "promised server push" as abstract from the frames that might get sent. If the language needs to improve to make this clearer then lets do it.
Does address this sufficiently, now that the description of push precedes this section? There's already a back-reference at the end of the paragraph if someone needs more details.
Closing; please reopen if you feel that does not sufficiently address this.
It would be a lot easier to read the spec if the lifecycle (which provides an overview of operation implicitly) came before the packet formats. Happy to provide a PR, but no point if the editors don't want it.
Thanks for the suggestion. I can see this either way. The ordering was intended to follow the HTTP/2 pattern of "framing layer, putting HTTP on the framing layer." The QUIC spec's new layout of successive layers of detail (concepts, then specific mechanisms, then wire format) would suggest putting frame specifics last.

PR not necessary -- it's a straightforward change if we decide to reorder this way.
I just suggested this change the other day, because I had the same issue. In particular, talking about the multiple push frames before introducing what push is is very awkward.
I like this new layout.Thanks Mike, this works for me!
Change:
innocuous dummy one (this is required for technical conformance with RFC7540; Section 9.2.) <ins> If the server does not provide an "encrypted_server_name" extension in EncryptedExtensions, the client MUST abort the connection with an "illegal_parameter" alert.  Moreover, it MUST check that PaddedServerNameList.nonce matches the value of the "encrypted_server_name" extension provided by the server, and otherwise abort the connection with an "illegal_parameter" alert. </ins> 5.2. Upon receiving an "encrypted_server_name" extension, the client-

Discussion:
This is a proposal to address the misrouting and key share replacement attacks identified by Ekr, Karthik, and Benjamin. Please help me improve it!
Some minor nits.
Change:
"external": The signature key at the index indicated by "sender_index" in the "external_senders" group context extension (see external-senders-extension).  The "content_type" of the <del> message MUST be "proposal". </del> <ins> message MUST be "proposal" and the "proposal_type" MUST be a value that is allowed for external senders. </ins> "new_member_commit": The signature key in the LeafNode in the Commit's path (see joining-via-external-commits).  The

Discussion:
NAME and I have completed interop testing that covers all of the functionality in the spec. We found a couple of places where there were ambiguities in the spec that led to different implementation decisions, and in the process of resolving those, found a couple of errors / omissions in drarft-19. The current PSK proposal validation forbids with other than . The branch and reinit sections call for the creation of PSK proposals with types and . Given the text in the PSK section, these proposals would be invalid. This PR explicitly allows and in the specific context of those operations. (This is a little pro-forma, since the PSK proposals are only seen by the committer. But it seems good to allow the committer to have consistent PSK proposal validation logic.) The text says that Add, Remove, and ReInit proposals can be sent by external senders, but is silent about other proposal types. This PR explicitly indicates which proposal types may be originated by external senders, and adds an IANA registry column to track. GREASE values for proposal types, credential types, and extension types are defined for use in Capabilities, but nothing currently forbids their use elsewhere. This PR forbids their use in actual Proposal or Credential objects, and in GroupContext extensions. The field of the Proposal object was inconsistently referred to as both and . This PR changes it to be everywhere.
Merge when ready.
Change:
10. <ins> Using Oblivious HTTP adds both cryptographic and latency to requests relative to a simple HTTP request-response exchange.  Deploying proxy services that are on path between clients and servers avoids adding significant additional delay due to network topology.  A study of a similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency. Oblivious HTTP might be incompatible with network interception regimes, such as those that rely on configuring clients with trust anchors and intercepting TLS connections.  While TLS might be intercepted successfully, interception middleboxes devices might not receive updates that would allow Oblivious HTTP to be correctly identified using the media types defined in media-types. Oblivious HTTP has a simple key management design that is not trivially altered to enable interception by intermediaries.  Clients that are configured to enable interception might choose to disable Oblivious HTTP in order to ensure that content is accessible to middleboxes. 11. </ins> Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] with the registration information in media-types for the media types "message/ ohttp-req", "message/ohttp-res", and "application/ohttp-keys". <del> 11.  References </del> <ins> 12.  References </ins> <del> 11.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types

Discussion:
I wanted to add more then just interception text here. So I added a little about performance and the ODoH study made some of those costs clear enough to cite. I anticipate this section growing over time. Some of the material we might add is already in other sections of the doc (DoS management at the proxy, for example), but we might move that around some. I also expect the working group to focus rather narrowly on this topic. Let's leave this open so that we have something to point to for IETF discussions.
Change:
additional properties which apply to a specific QUIC version, or to a range of QUIC versions. <del> 5. </del> <ins> 6. </ins> A QUIC endpoint that receives a packet with a long header and a version it either does not understand or does not support might send

Discussion:
Remove the normative reference to -transport in -invariants. This is an editorial change, but I'll pass it to the list. Includes some consistency updates.
Yes, but I think that - at least in principle - each should be as independent of the other as possible. Sure, -transport is a concrete instantiation of -invariants, but you can implement it without -invariants. Similarly, -invariants exists to support -transport, but it describes something bigger than it. So while we might have some pointers, you can read each without the other, which is nice.
introduced a new bespoke packet format. I don't have issues with the format itself, but as I reviewed I was surprised to see it used there without any explanation as to how to decipher it. I think it would be nicer if each document that uses this format either: References the "Notational Conventions" section from draft-ietf-quic-transport Has a "Notational Conventions" section of its own explaining this format
-- URL There is a lot more that the document leans on than the packet format grammar, so any expansion of this might explode. I tend to think that this is adequate.
I agree that the reference is sufficient, except for one aspect: We do want the invariants drafts to be readable without needing to get into the v1 spec, because the target audience is people who need to handle QUIC without regard to versions. I think it's wrong that the reference to QUIC-TRANSPORT is normative instead of informative, and this reference for conventions and definitions is the only reference in the doc that actually needs to be normative. I'm almost be more inclined to move the notation definition across, just as we ultimately did for the definition of VN, and let -transport refer to -invariants for it.
Looks good. Technically, we could reference this draft for the notation, but we don't need to if it makes transport easier to read.
Change:
Any keys presented by the client instance to the AS or RS MUST be validated as part of the request in which they are presented.  The type of binding used is indicated by the "proof" parameter of the key <del> object in key-format.  This parameter is formally specified by an object with at least the following member: </del> <ins> object in key-format.  Key proof methods are specified either by a string, which consists of the key proof method name on its own, or by a JSON object with one required field and any number of optional parameters defined by the method: </ins> <del> Individual methods MAY define additional parameters as members in this object. </del> <ins> Individual methods defined as objects MAY define additional parameters as members in this object. </ins> Values for the "method" defined by this specification are as follows: Additional proofing methods are defined by the IANA-key-proof- methods. <del> For example, the "httpsig" method can be specified with its parameters as: </del> <ins> In cases where a method's parameters can be set to omitted or set to default values, methods MAY be defined as both an object and a string.  For example, the "httpsig" method can be specified as an object with its parameters explicitly declared, such as: </ins> <del> If additional parameters are not required or used for a specific method, the method MAY be passed as a string instead of an object. For example, the "mtls" method with no additional parameters could be sent by the client instance as: </del> <ins> The "httpsig" method also defines defines default behavior when it is passed as a string form: </ins> <del> The AS would map this to the equivalent expanded form as follows: </del> <ins> This is explicitly defined as the signature algorithm specified by the associated key material and the content digest is calculated using sha-512. </ins> All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would

Discussion:
This reformats the object-type key proofs to be defined in terms of types, in parallel with interaction start methods. Now instead of default field values, you can have either an object with parameters or a string with strictly specified behavior. This should be less susceptible to confusion than the previous definition which allowed partial objects and implied a large set of possible combinations that the receiver would have to deal with.
To edit notification comments on pull requests, go to your .
Makes sense, it's aligned with the behaviour of the rest of the doc
Change:
initially registered by either themselves, or by their peer. Endpoints MAY use the CLOSE_DATAGRAM_CONTEXT capsule to immediately reject a context that was just registered using a <del> REGISTER_DATAGRAM_CONTEXT capsule if they find its Extension String to be unacceptable. </del> <ins> REGISTER_DATAGRAM_CONTEXT capsule if they find its Context Extensions field to be unacceptable. </ins> After an endpoint has either sent or received a CLOSE_DATAGRAM_CONTEXT frame, it MUST NOT send any DATAGRAM frames

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:
All of the below properties are optional (e.g., it is possible to specify "User Timeout Enabled" as true, but not specify an Advertised User Timeout value; in this case, the TCP default will be used). <ins> These properties reflect the API extension specified in Section 3 of RFC5482. </ins> 7.2.1.

Discussion:
, . Partially addresses .
sec 7.2 perhaps I'm not thinking of this correctly, but should there be a way to query the peer-offered user timeout?
This looks protocol-specific (it's not a generic transport function). QUIC could let you query it in a protocol-specific property. Proposing moving to the QUIC mapping doc.
I agree with addressing this in the QUIC mapping doc, but for clarification: this is protocol-specific already (it's about a protocol-specific TCP property), and I added a clarification that the API calls reflect the API specified in Section 3 of RFC 5482 (which doesn't include this functionality). => I agree that allowing to query the peer's UTO might be useful, but it's probably not worth adding more text for this, as I also suspect that nobody will implement this for TCP anyway (even the underlying logic from RFC 5482 isn't widely available either AFAIK). If someone does, they are still free to allow querying whatever they like ... but IMO, we shouldn't make this document longer with more protocol-specific elements than we absolutely need to include.
Can we close the Peer user timeout with no-action?
I temporarily gave this a "discuss" label to see if it provokes people to have a 1-minute chat about closing this. This didn't happen, so now I just closed it.
sec 7.1.8 This section is missing a reference to minSendRate and minRecvRate
sec 6.2 "After Stop() is called, the Listener can be disposed of." I don't understand the difference between calling URL() and simply disposing of the object. Does this imply that there is a URL() that allows a configured listener to resume?
We should just not talk about "disposing" here. Just remove the sentence.
Object disposal implies a language with synchronous destruction, something we can't assume. For something garbage collected, you'd need an explicit close method because you don't know when the object will be destroyed.
sec 5.2.9 It would be helpful to say "Applications that neither prohibit nor require congestion should query the result and disable their own congestion control if present in the transport"
Interesting, but we need to be careful in what we say.

It seems safe, but not performant to do CC at multiple layers, and if it's done at a lower layer performance might be improved by not replicating the function at a higher layer...
Link to UDP guidelines document. Just mention that there are performance implications of multiple CC loops; don't just say "disable CC".
Change:
Moreover, Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of <del> secure protocols.  For example, if an application requests TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. </del> <ins> secure protocols.  For example, if an application requests a specific version of TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. Alternatively, a Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. </ins>

Discussion:
Following , Section 4.2.3 of the Architecture document now says that fallback between different security protocol versions might be allowed. The Security Considerations section was out of sync. This PR fixes that.
Change:
string "s" is indicated using the function "encode_str(s)".  The function "len()" returns the length of a sequence of bytes. <del> Formats are described using notation from QUIC. </del> <ins> Formats are described using notation from QUIC.  An extension to that notation expresses the number of bits in a field using a simple mathematical function. </ins> 3.

Discussion:
In Section 4, there are two statements for Encapsulated Request and Encapsulate Response respectively These are the only places that is used. The HPKE spec doesn't use the term either. Doing some digging, it seemed like an older draft defined this term (and others); see URL But it seems like you moved away from that and this is a hangover
So this isn't ideal. It is also wrong. It would be HpkeKemId in the first instance and HpkeAeadId in the second. The second also refers to Nenc without using it. The second also neglected to mention Nn, which was in the algorithm. What a mess. I've cleaned it up, but would appreciate someone double-checking my work.
This addresses the issue I created, thanks. I can't vouch for the correctness of the crypto pieces though