jiebi/CodeConvo huggingface dataset:
Change:
The "tree" field contains the public keys corresponding to the nodes of the ratchet tree for this group.  The length of this <del> vector MUST be "2*size + 1", where "size" is the length of the </del> <ins> vector MUST be "2*size - 1", where "size" is the length of the </ins> roster, since this is the number of nodes in a tree with "size" leaves, according to the structure described in ratchet-trees.

Discussion:
I'm approving these changes given the current state of the document, but I filed because the KDF stuff is broken. Please make HPKE a normative reference (since it's required to implement). Since it's an Internet-Draft, you don't need to add it to the references section, you can just reference it directly as and the Markdown processor will add the reference. (Change the to for an informative reference.)
Change:
SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections as per RFC8858. <del> While this version of the specification only supports, at most, a single audio and video track in a single media stream. (therefore, all "m=" sections MUST contain an "msid" attribute with the same value as per [[!RFC8830]]), in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a "406 Not Acceptable" error response. </del> <ins> This version of the specification only supports, at most, a single audio and video MediaStreamTrack in a single MediaStream as defined in [[!RFC8830]] and therefore, all "m=" sections MUST contain an "msid" attribute with the same value.  However, it would be possible for future revisions of this spec to allow more than a single MediaStream or MediaStreamTrack of each media kind, so in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a "406 Not Acceptable" error response. </ins> Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m=" sections as per RFC8829 section 5.3.1 in case there is any error

Discussion:
Looks good.
thank you Bernard!
from NAME Section 2 I do not see a definition of “track”. I think this is important to clarify. Section 4.2 “ While this version of the specification only supports a single audio and video track, in order to ensure forward compatibility, if the number of audio and or video tracks or number streams is not supported by the WHIP Endpoint, it MUST reject the HTTP POST request with a "406 Not Acceptable" error response.”
updated the PR to add MediaStream/MediaStreamTrack references
Change:
then another trivial attack is possible. Let the group of peers who know the key be "A", "B", and "C".  The <del> attack proceeds as follows.  1.  "A" sends a "ClientHello" to "B", without including a key share 2.  The handshake completes as expected </del> <ins> attack proceeds as follows: "A" sends a "ClientHello" to "B", without including a key share. The handshake completes as expected. </ins> This attack violates the secrecy of session keys property, because even an honest but curious "C" can decrypt the session between "A"

Discussion:
Addresses , , and .
... and don’t prohibit or otherwise interfere with PAKEs. (Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band.)
Fixed in .
Fixed in .
Start with the general recommendation and invariant: Identities should be unique across all nodes, roles, and keys. For each use case, how a part of the invariant is violated and leads to one of the known attacks.
Fixed in .
Change:
this structure does not preclude a protocol to use one of the individual structures as a stand alone component. <del> This structure is encoded as an array by CBOR.  Descriptions of the fields: indicates which of the security structures is in this block. contains the top level fields for the security service provided. The type in this field is based on the value of the field msg_type. msg_type 1 is used for COSE_sign msg_type 2 is used for COSE_encrypt msg_type 3 is used for COSE_mac </del> <ins> The top level of each of the COSE message structures are encoded as arrays. We use an integer to distingish bettwen the different security message types.  By looking at the integer in the first element, one can determine which security message is being used and thus what the syntax is for the rest of the elements in the array. Implementations SHOULD be prepared to find an integer in the location which does not correspond to the values 0 to 2.  If this is found then the client MUST stop attempting to parse the structure and fail. Clients need to recognize that the set of values could be extended at a later date, but should not provide a security service based on guesses of what is there. NOTE: Alternative syntax with tags would be Where we would need to define the latter two as tagged arrays like is currently done for COSE_SignedMessage. There is no space savings in CBOR, this is strictly about using CBOR paradymes.  It is not clear what would happen if a JOSE serialization appeared, but that is probably not interesting.  If this path is used, then there is no extensibility for new messages types.  They would need to be defined on their own. </ins> 3.

Discussion:
Fix some additional errors found in the CDDL descriptions. It is still not completely correct so automatic testing is not turned on yet. Also some of the examples were out of date to the expected syntax so they got some updates.
Change:
server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an <del> extension in the CertificateEntry containing the assoiciated </del> <ins> extension in the CertificateEntry containing the associated </ins> certificate.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961

Discussion:
I believe that these are just cleanup, though you might want to check the PSK one a little more carefully (happy to separate it if it is a problem).
We seem to have reached consensus that the record layer will use the AEAD form only. The stream and CBC forms will be removed.
Fixed.
Change:
for this connection received on the old IP address, but MAY continue to process delayed packets. <ins> The addresses that a server provides in the preferred_address transport parameter are only valid for the connection in which they are provided.  A client MUST NOT use these for other connections, including connections that are resumed from the current connection. </ins> 9.6.3. A client might need to perform a connection migration before it has

Discussion:
This just writes down what NAME suggested in .
Two things need to be clarified around SPA: The CID is not path-specific; it's there to ensure that the client has a second CID before the handshake completes. If the client opts not to migrate, the client can use that CID on the The IP addresses in the SPA are only for use in the transition post-handshake; the client should not cache the IP addresses for any other use.
(Just filling in the text here) on the original address from the server, which is the existing connection, not-migrated. +1 to the second point
If the server is telling the client to migrate to a SPA, should this be changed to "the client MUST select one of the two server's preferred addresses ..."? If the text remains a SHOULD, and the client stays on the old server address, what can the server do if it is only willing to continue with the new connection on the SPA? The server could close the initial connection using the old server address but there isn't a transport error code (e.g. MIGRATION_ERROR) that would explicitly tell the client why the connection is being closed.
The "SHOULD" is intentional. A server cannot rely on clients moving.
Then perhaps a cautionary note such as "If the client opts not to migrate to a preferred address, the server may [lower case] decide to close the connection (e.g. SERVER_BUSY)".
If the server isn't willing at all to handle connections on its published IP address, then (naively) it shouldn't accept connections on that IP address and should publish the other one instead. The scenario this targets is that it's somehow better for the client to use a different address, but that other address can't necessarily be known in advance.
Migrating to a unicast address avoids having to perform connection-based routing through a load balancer.
Change:
5.5. <del> When packet protection keys are discarded (see Section 4.9 of QUIC- </del> <ins> When packet protection keys are discarded (see Section 4.10 of QUIC- </ins> TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed anymore.  The sender MUST discard all recovery state associated with

Discussion:
and 4.9.1 are now 4.10 and 4.10.1, I believe.
Change:
This is technically already possible (since the server controls both the HTTP resources it exposes and the use of browser APIs by its <del> content), but standardisation might make this easier to accomplish. </del> <ins> content), but standardization might make this easier to accomplish. </ins> Note that in this second use, the browser does not consult the DOH server or use its responses for any DNS lookups outside the scope of

Discussion:
minor editoral changes
thanks for these. The only one that's a little iffy is the inclusion of the reason phrase for 415... but I think here its giving more explanatory value than an impression that particular phrase needs to be used (which wouldn't jibe with http details).
Change:
Discussion of this document takes place on the GitHub@ietf mailing list (ietf-and-github@ietf.org), which is archived at <del> https://mailarchive.ietf.org/arch/search?email_list=ietf-and-github [1]. </del> <ins> <https://mailarchive.ietf.org/arch/search?email_list=ietf-and- github>. </ins> Source for this draft and an issue tracker can be found at <del> https://github.com/ietf-gitwg/using-github [2]. </del> <ins> <https://github.com/ietf-gitwg/using-github>. </ins> 1. The IETF has an open and transparent process for developing <del> standards.  The use of GitHub [3] or similar tools, when used as part </del> <ins> standards.  The use of GitHub [1] or similar tools, when used as part </ins> of this process, can have several objectives.  GitHub provides tools that can be helpful in editing documents.  Use of this service has been found to reduce the time that Working Groups need to produce

Discussion:
From Adam's AD review
Note that the URL fixes here are ineffective. The source is: The resulting XML is: The HTML shows a nice clickable link. xml2rfc produces text output of "URL (URL)". Perhaps this is a case where a small tweak to xml2rfc is in order.
Nice relaxation of the text.
Change:
Flags 8-31 are for standards-track documents that the experts believe will see wide adoption among either all users of TLS or a significant group of TLS users.  For example, an extension that <del> will be used by all web clients or all smart objects. </del> <ins> will be used by all web clients or all smart objects.  The only entry in the initial registry is from this range. </ins> Flags 32-63 are for other documents, including experimental, that are likely to see significant adoption.

Discussion:
Show the initial registry value is a decimal number rather than a hex number.
LGTM.
Change:
10.4. <del> Connectedness: Unconnected </del> <ins> Connectedness: Connectionless </ins> Data Unit: Datagram

Discussion:
Just check "connected" - in case we mean connection-oriented; and that usage of "connect" is sane, we need care.
UDP is best described as connectionless, not unconnected: it has no notion of a connection, where "unconnected" might imply a particular usage pattern for a protocol that also supports connections.
YES! UDP is "connectionless"; confusing APIs do support a "connected mode". Please remove unconnected.
Change:
An opaque blob that the client can use with a future Initial packet.  The token MUST NOT be empty.  A client MUST treat receipt <del> of a NEW_TOKEN frame with </del> <ins> of a NEW_TOKEN frame with an empty Token field as a connection error of type FRAME_ENCODING_ERROR. </ins> A client might receive multiple NEW_TOKEN frames that contain the same token value if packets containing the frame are incorrectly

Discussion:
I looked into the commits but I cannot identify the commit which removed this line.
Gah! Thanks NAME for catching this!!
Change:
expression that yields true, such as "1 == 1", and "F" is any expression that yields false, such as "1 == 0"): <del> 3.4.8.3. </del> <ins> 3.4.7.3. </ins> JSON: Queries: <del> 3.4.9. </del> <ins> 3.4.8. </ins> The list selector allows combining member names, array indices, slices, and filters in a single selector.

Discussion:
I want to take the opportunity of there being no PRs in flight to make this purely editorial change to the order of the spec. It avoids unnecessary forward references to the filter and list selectors.
Another PR opened and merged in less than 8 hours...
Please note this PR was purely editorial. It moved some text around. but didn't change it. (I was planning to merge this later today after a bit more time.)
We should just have a flat policy of 24 hrs for a PR to ensure everyone gets to see it. It doesn't matter if it was a spelling change. Everyone should have a chance to review it.
It's one thing to agree to this policy, which I think we have, and quite another to remember to apply it when one is focussed on other things. I've raised a about automating this check.
Have we? It is not policy I would normally agree to. Editors need to be able to do their work. Github is here to help, not to hinder.
Ah, my mistake: I agreed.
We have a two-week policy for PRs in JSON Schema and it's very helpful to encourage cooperation. I don't think 24 hrs is too much to ask.
Please explain how you did not get a chance to review this change.
The PR opened at 3AM and merged at 10AM. This is an insufficient window. 24 hrs, please. It's not a big request.
You have had time to review after merge. How is a merge such an important event?
If I have objections to a PR, they should be voiced before it's merged. Reviewing after the fact is pointless. Any damage has been done. This particular PR is not one of those cases, but in general, everyone involved should get a chance to review. Why are you so opposed to this? It's one day. That's all I'm asking.
Thanks!
Change:
Template Keys", on the Transport Layer Security (TLS) Parameters page, with a "Specification Required" registration policy and the following initial contents: <ins> 6.3. This document requests that IANA open a new registry entitled "Well- known cTLS Profile IDs", on the Transport Layer Security (TLS) Parameters page, with the following columns: ID value: A sequence of 1-4 octets. Template: A JSON object. Note: An explanation or reference. The ID values of length 1 are subject to a "Standards Action" registry policy.  Values of length 2 are subject to an "RFC Required" policy.  Values of length 3 and 4 are subject to a "First Come First Served" policy.  Values longer than 4 octets are not subject to registration and MUST NOT appear in this registry. The initial registry contents are: </ins>

Discussion:
This change also reserves short profile IDs for "well-known" use. Fixes URL
Can we please try to resolve this question soon to unblock implementation?
NAME NAME Any objection to merging this?
The template says it's an integer (in what range?), but the ClientHello says it's 0-255 bytes. I think it's probably easiest to say it's a string of 0-255 bytes, with the empty string reserved to mean "no template". I guess if you want to get fancy you could reserve all 1-4 byte strings.
Agreed. If you want to send a PR, I wouldn't object.
This LGTM.
Change:
Each Push ID MUST only be used once in a push stream header.  If a push stream header includes a Push ID that was used in another push stream header, the client MUST treat this as a connection error of <del> type HTTP_DUPLICATE_PUSH. </del> <ins> type HTTP_ID_ERROR. </ins> 6.2.3.

Discussion:
Implements suggestions from
Updated to replace HTTPLIMITEXCEEDED and HTTPPUSHIDERROR with the single error HTTPID_ERROR.
There are presently a few cases where the Push ID can be used incorrectly. The table shows current error codes, proposes replacing the HTTPDUPLICATEPUSH with an HTTPPUSHIDERROR code, and replaces use of HTTPMALFORMED frame. Note, on I suggested a slightly different solution to replace HTTPMALFORMED FRAME, but I think this is a better path.
To me it seems that having an error code for specific part of push (i.e. ID of push-related information being incorrect) a bit too detailed. I think it sticks out, because we do not have things like "IDERROR, STREAMIDERROR. Also, using PUSHIDERROR in some cases while using MALFORMEDFRAME in others seems confusing. I think we might want to consider doing either of the two: Use PUSHIDERROR (or a generic error code for push) for all the push-related errors. This makes sense if we consider push as an optional feature of HTTP/3 Introduce IDERROR that captures all the limit and ID errors.
Thanks NAME The proposal is a bit of a compromise, so I agree with some of the points that you make. I like your idea of replacing HTTPLIMITEXCEEDED with HTTPIDERROR. I think it solves the issue in the most general way and doesn't change the protocol mechanics. What follows is the response I made first, before coming to that agreement :) Right. The difference here is that H3 frames only reference the stream and placeholder ID spaces, they don't control them. So, if the peer references an ID that doesn't exist then respond with HTTPLIMITEXCEEDED. Multiple references to the same ID is a little different, its ok to reuse placeholder ID (as long as the above condition holds, and you create a semantically valid PRIORITY frame). The transport spec discusses reuse of stream IDs at that layer; in H3 we only use stream ID for PRIORITY and GOAWAY - this has similar restrictions. However, server push is a little different because it's ID space is managed by the MAXPUSHID frame. The three errors that use HTTPPUSHIDERROR are unique to push.

However, if we modified HTTPLIMITEXCEEDED to cover exceeding limits and incorrect ID usage (call it HTTPID_ERROR) I think that would work.
I updated the PR with the above, so that we can see what it looks like.
I'm not totally sold on this, but I'm having trouble articulating what it is that doesn't flow for me. I suspect that means I don't actually disagree, I just need some time to wrap my head around it.
We merged so I'm closing this as completed.
Change:
process of identifying options for connecting, such as resolution of the Remote Endpoint, occurs in response to the Initiate call. <del> Listen: Enables a listener to accept incoming Connections.  The </del> <ins> Listen: Enables a listener to accept incoming connections.  The </ins> Listener will then create Connection objects as incoming connections are accepted (events).  Listeners by default register with multiple paths, protocols, and Local Endpoints, unless

Discussion:
URL The use of Cap 'C' in the first sentence for connection is confusing. The Connection object is created after the incoming connections are accepted. The Cap C makes it assume that it not that case and create an expectation that the remote is also a TAPS implementation.
Change:
another example, some systems require the provisioning process to embed application-specific information in either PSKs or their identities.  Identities may sometimes need to be routable, as is <del> currently under discussion for EAP-TLS. </del> <ins> currently under discussion for EAP-TLS-PSK. </ins> 3.3.

Discussion:
Moved links in use cases sections to references and made the text somewhat more concise. Added some initial text on known attacks.
Change:
fields, each of which has a fixed index over time.  Its entries are defined in static-table. <ins> All entries in the static table have a name and a value.  However, values can be empty (that is, have a length of 0). </ins> Note the QPACK static table is indexed from 0, whereas the HPACK static table is indexed from 1.

Discussion:
A couple of clarifications that can be useful to people who are looking at *PACK for the first time like myself. Not sure about the normative language though. I can reword it if necessary.
Let's see how handles it: We could simply add similar verbiage to Sections and 4.5.5. of the QPACK draft instead.
NAME I can add something like that, but TBH I don't think that the HPACK wording would have helped me, so I'd rather keep my clarification (that says "ignore value") as well.
This wording seems fine.
Change:
A server MUST validate that the ticket_age is within a small tolerance of the time since the ticket was issued (see replay-time). <del> All of the parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.)  MUST be those which were negotiated in the connection </del> <ins> The parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.) are the same as those which were negotiated in the connection </ins> which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension.

Discussion:
We currently have "identical" but Ilari argues we should have more specific rules
From Ilari: "Here is what I think should match (going through all currently known values and excetions): Version Ciphersuite Protection+PRF, key exchange in allowed values. What to do with servername??? Statusrequest presence (but not contents)??? Statusrequestv2 presence (but not contents)??? Signedcertificatetimestamp presence (but not contents)??? ALP can not be negotiated by any means. 0-RTT Protection+PRF+ALP can not be negotiated. (I think statusrequest and statusrequestv2 should mirror whatever signedcertificatetimestamp does). Also, that servername is just its own kind of mess, where what is the proper thing isn't at all obvious. And here is the list of extensions that are allowed to be negotiated with 0-RTT (parenthesis denotes extensions where things depend on exact handling discussed above). (servername) maxframgmentlength (statusrequest) supportedgroups usesrtp heartbeat (statusrequestv2) (signedcertificatetimestamp) tokenbinding [I-D stage] cachedinfo? keyshare presharedkey earlydata (required for obvious reasons) (Note: applicationlayerprotocol_negotiation is not on this list, very much intentionally, since negotiation of ALP is not possible in presence of 0-RTT. Don't even try)."
More from Ilari: Thinking about it some more, including statusrequest/statusrequestv2/ signedcertificatetimestamp is only useful if one wants to tie the ticket lifetime to parent certificate lifetime. Also, list of things saved for 0-RTT-capable context would be useful. I presume: The context name The PSK key The PSK context Timestamp Expiry time (not needed for 0-RTT) On server side: RTT estimate Allowed key exchanges Negotiated protection Negotiated PRF Negotiated ALP (negotiated via any means, or absence thereof) (Implementation-defined peer identity, not needed for 0-RTT) (Implementation-defined self identity, not needed for 0-RTT) What to do with servername??? (On server side, one can save the rest encrypted into context name).
Change:
Discussion of this draft takes place on the HTTP working group mailing list (httpapi@ietf.org), which is archived at <del> https://lists.w3.org/Archives/Public/ietf-httpapi-wg/ [1]. </del> <ins> https://mailarchive.ietf.org/arch/browse/httpapi/ [1]. </ins> The source code and issues list for this draft can be found at https://github.com/ietf-wg-httpapi/ratelimit-headers [2].

Discussion:
Hi The link to the mailing archive (URL) is 404. I assume the correct link is: URL
Hi NAME thanks for the report, should be fixed soon.