jiebi/CodeConvo huggingface dataset:
Change:
for other control processes, and a short header that may be used for data transmission in an established connection.  While the long header always exposes some information (such as the version and <del> Connection IDs), the short header exposes at most only a single Connection ID. Note that the Connection ID in the short header may be omitted.  This is a per-connection configuration option; if the Connection ID is not present, then the peer omitting the connection ID needs to use the same local address for the lifetime of the connection and connection migration is not supported for that direction of the connection. </del> <ins> connection IDs), the short header exposes at most only a single connection ID. Aside from the Destination Connection ID field of the first packets sent by clients, the connection ID can be zero length.  This is a choice that is made by each endpoint individually. An endpoint that selects a zero-length connection ID will receive packets with a zero-length Destination Connection ID.  The endpoint needs to use other information, such as its IP address and port number to identify which connection is referred to.  An endpoint can choose to use the source IP address and port on datagrams, but this could mean that the endpoint is unable to match datagrams to connections successfully if these values change, making migration effectively impossible. </ins> 9.1. <del> QUIC supports a server-generated Connection ID, transmitted to the </del> <ins> QUIC supports a server-generated connection ID, transmitted to the </ins> client during connection establishment (see Section 7.2 of QUIC). <del> Servers behind load balancers may need to change the Connection ID </del> <ins> Servers behind load balancers may need to change the connection ID </ins> during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support <del> stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without retaining connection state. </del> <ins> stateless load balancing. Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently routes packets to the correct server instance.  This might require coordination between servers and infrastructure.  One method of achieving this involves encoding routing information into the connection ID.  This ensures that there is no need to for servers and infrastructure to coordinate routing information for each connection. See further QUIC-LB. </ins> 9.2.

Discussion:
Quite a few pieces of text in here that needed corrections. As before, I'm happy to pull out individual commits so we can discuss.
Change:
This document registers the "PrivateToken" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme <del> Registry" defined in RFC9110. </del> <ins> Registry" defined in RFC9110, Section 16.4. </ins> Authentication Scheme Name: PrivateToken

Discussion:
Previously, the document linked to RFC 7235, whose whole purpose was to discuss HTTP Authentication. Now you kjust link to RFC 9110, which all of HTTP semantics. Suggest that you link to Section 11 of RFC 9110 to make the reader's life easier.
Change:
RFC3339 for representing additional information including a time zone. <ins> It updates RFC3339 in the specific interpretation of the local offset "Z", which is no longer understood to "imply that UTC is the preferred reference point for the specified time"; see update. </ins> 1. Dates and times are used in a very diverse set of internet

Discussion:
Section 3.3 is not yet updated (but will clearly change a lot) (As discussed at IETF 114)
cc NAME
Hi NAME NAME - what are the next steps on this PR?
NAME NAME - Is there any update on this PR?
There isn't yet, but vacation time has officially ended in Europe... RSN.
Looks great! Thanks for bringing all these edits together. I left one minor comment in case you'd want to make that change, but also OK to merge if you don't think it's needed.
Change:
If the exchange was an update of access rights, i.e., a new Security Context was derived from a client that already had a Security Context in place, the RS is RECOMMENDED to delete the old Security Context <del> after OSCORE verification and verification of access rights succeed. The RS MUST delete the Security Context if it deletes the access token associated to it. </del> <ins> after OSCORE verification succeeds.  The RS MUST delete the Security Context if it deletes the access token associated to it. </ins> 4.4.

Discussion:
Not much here, though a couple points I'll leave some further comments on, as the proper disposition is not entirely clear.
If you agree NAME I would go ahead and merge this PR (excluding the "update of access rights" change at l.776).
Sorry, I missed this when it came in. Please go ahead.
Change:
Firstly, "$" produces a nodelist consisting of just the argument. <del> Next, ".a" selects from any input node of type object and selects the node of any member value of the input node corresponding to the member name ""a"".  The result is again a list of one node: </del> <ins> Next, ".a" selects from any object input node and selects the node of any member value of the input node corresponding to the member name ""a"".  The result is again a list of one node: </ins> "[{"b":0},{"b":1},{"c":2}]". <del> Next, "[*]" selects from an input node of type array all its elements (if the input node were of type object, it would select all its member values, but not the member names).  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </del> <ins> Next, "[*]" selects from any array input node all its elements (for an object input node, it would select all its member values, but not the member names).  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </ins> <del> Finally, ".b" selects from any input node of type object with a member name "b" and selects the node of the member value of the input node corresponding to that name.  The result is a list containing "0", "1".  This is the concatenation of three lists, two of length one containing "0", "1", respectively, and one of length zero. </del> <ins> Finally, ".b" selects from any object input node with a member name "b" and selects the node of the member value of the input node corresponding to that name.  The result is a list containing "0", "1".  This is the concatenation of three lists, two of length one containing "0", "1", respectively, and one of length zero. </ins> As a consequence of this approach, if any of the segments produces an empty nodelist, then the whole query produces an empty nodelist.

Discussion:
JSON types are not used much in the JSON spec. It is debatable whether there really is a boolean type or simply the values and . Also, the JSONPath spec doesn't really benefit from this term.
I think this reads well without breaking any semantics.
Change:
(e.g. a finite number of decoders), createOffer should return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those <del> resources.  Because this method may need to inspect the system state to determine the currently available resources, it may be implemented as an async operation. </del> <ins> resources. </ins> Calling this method may do things such as generate new ICE credentials, but does not result in candidate gathering, or cause

Discussion:
Section 4.1.5 createOffer: The statement about this being async is either a requirement or out of scope. I'd suggest out of scope (it is purely an API property); the alternative is saying "it is an async operation".
Change:
and processed packet indices.  If a packet arrives with an index that matches one in the replay list, it is silently discarded. <del> DTLS RFC5764 is commonly used as a way to perform mutual authentication and key agreement for SRTP RFC5763.  (Here, certificates marshal public keys between endpoints.  Thus, self- signed certificates may be used if peers do not mutually trust one another, as is common on the Internet.)  When DTLS is used, certificate fingerprints are transmitted out-of-band using SIP. Peers typically verify that DTLS-offered certificates match that which are offered over SIP.  This prevents active attacks on RTP, but not on the signaling (SIP or WebRTC) channel. </del> <ins> DTLS RFC5764 is commonly used to perform mutual authentication and key agreement for SRTP RFC5763.  Peers use DTLS to perform mutual certificate-based authentication on the media path, and to generate the SRTP master key.  Peer certificates can be issued and signed by a certificate authority.  Alternatively, certificates used in the DTLS exchange can be self-signed.  If they are self-signed, certificate fingerprints are included in the signalling exchange (e.g., in SIP or WebRTC), and used to bind the DTLS key exchange in the media plane to the signaling plane.  The combination of a mutually authenticated DTLS key exchange on the media path and a fingerprint sent in the signalling channel protects against active attacks on the media, provided the signalling can be trusted.  Signalling needs to be protected as described in, for example, SIP RFC3261 Authenticated Identity Management RFC4474 or the WebRTC security architecture I- D.ietf-rtcweb-security-arch, to provide complete system security. </ins> 3.5.2. <del> Optional replay protection with tunable replay windows. Out-of-order packet receipt. (RFC5763) Mandatory mutually authenticated key exchange. </del> Partial encryption, protecting media payloads and control packets but not data packet headers. Optional authentication of data packets; mandatory authentication of control packets. <ins> Optional replay protection with tunable replay windows. Out-of-order packet receipt. Mutually authenticated key exchange </ins> 3.5.3. <del> External key derivation and management mechanism or protocol, e.g., DTLS RFC5763. </del> <ins> External key derivation and management protocol, e.g., DTLS RFC5763. </ins> <del> External signaling protocol to manage RTP parameters and locate and identify peers, e.g., SIP RFC3261 or WebRTC I-D.ietf-rtcweb- security-arch. </del> <ins> External identity management protocol, e.g., SIP Authenticated Identity Management RFC4474, WebRTC Security Architecture I- D.ietf-rtcweb-security-arch. </ins> 3.6.

Discussion:
This attempts to make the description of DTLS+SRTP keying less confusing.
The description of how DTLS is used for establishing SRTP connections is confusing: is mutual auth in DTLS ever used, or is an OOB fingerprint via SIP always used? The text here needs to be clarified.
Change:
7.2. The "deprecation" link relation type should be added to the permanent <del> registry of link relation types (Section 4.2 of LINK). </del> <ins> registry of link relation types (LINK). </ins> 8.

Discussion:
This repo wasn't set up with the automated tooling; this PR corrects that, and fixes up a few other small things.
it seems like there's some problem with this update, NAME URL
Fixed.
Change:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level. </del> <ins> TODO: identity, rtcp-rsize, rtcp-mux, and any other attributes valid at session level. </ins> Once all the session-level lines have been parsed, processing continues with the lines in media sections.

Discussion:
This is all strictly editorial and I think if either of you give it a quick scan, you can just merge it
LGTM - will merge
Change:
A proxy MUST NOT add information about the client identity when forwarding requests.  This includes the Via field, the Forwarded <del> field FORWARDED, and any similar information. </del> <ins> field FORWARDED, and any similar information.  A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. </ins> 8.2.1.

Discussion:
But they should. Consider the case where clients have equal-sized messages, but are making requests using different key identifiers or different request targets. If that information could be linked to certain clients, encryption would increase the size of the anonymity set from the perspective of a passive observer for little extra cost.
Done. PTAL.
Clients and proxies create independent TLS connections to the upstream node in the OHTTP chain. This raises some interesting questions: What if the trust stores between client and proxy are disjoint? What if the proxy completely disables server authentication in its connection to the target? The does not assume a secure connection between proxy and target, so I don't think this has an effect on the security properties of OHTTP. That said, it may be worth noting explicitly, if we don't already do so.
Yeah, the same applies here. We rely on the proxy not leaking certain information, but that does not necessarily extend to a reliance on TLS for that hop. Worth noting.
Change:
"true", "false", and "null" are lower-case only (case-sensitive). <del> The syntax of regular expressions in the string-literals on the right-hand side of "=~" is as defined in I-D.draft-ietf-jsonpath- iregexp. </del> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).

Discussion:
Weirdly, I cannot reply to this observation: URL Expiry is somewhat unusual for IANA registries (early allocations do expire). What is the behavior you would expect implementations to exhibit? The function extension to stop working on the expiry day?
Hey NAME based on this useful-looking discussion, do you plan to revise this significantly? I'm wondering if I should give it a careful read now or wait for an updated version.
Definitely. Of course, I'd like to have your input on the points raised (the non-trivial ones). We might even want to have a design-team meeting...
Might be a good idea to mark the non-non-trivial issues above resolved, to help reviewer focus. If it's OK, I'll wait for the next revision to go end-to-end. Agreed on a design meeting.
Here's my list of items where we could use input: More frugal with allowing whitespace? return value of functions that don't get the right arguments (e.g., length(1)) (interaction with -- non-singular paths in exist-expr) IANA designated expert instructions (frugal with "good" names) expiring reservations? (shades of certificates) domain of length (arrays now, add strings, objects?)? should there be another function for the size of nodelists (size())? Probably mostly resolved: for function names (ASCII, lowercase, only)
NAME I rebased this and resolved some conflicts.
Update: Address whitespace in a separate PR, if desired. Semantic issue: What to do with value of wrong kind? Fixed in 08dd7ad Fixed in afda44a Probably not. Semantic issue: What to do with value of wrong kind? Yes, that is called count() now (e3a565a) Let's stick with that name space.
We may be able to make this syntactically invalid. See URL for some ideas.
Change:
Compute the shared secret Z with the node's other child <del> Generate a fresh nonce N </del> <ins> Derive a key and nonce as described below </ins> Encrypt the node's secret value using the AEAD algorithm specified by the ciphersuite in use, with the following inputs: <del> Key: A key derived from Z as specified by the ciphersuite </del> <ins> Key: The key derived from Z </ins> <del> Nonce: A random nonce N of the size required by the algorithm </del> <ins> Nonce: The nonce derived from Z </ins> Additional Authenticated Data: The empty octet string

Discussion:
This matches the behavior in TLS, and saves space (due to not having to send the nonce).
Merging based on r+ from NAME out of band
Change:
The client then constructs an encapsulated request, "enc_request", as follows: <del> Compute an HPKE context using "pkR" and a label of "ohttp </del> <ins> Compute an HPKE context using "pkR" and a label of "message/bhttp </ins> request", yielding "context" and encapsulation key "enc". Construct associated data, "aad", by concatenating the values of

Discussion:
Test vectors generated from the .
With , we're enforcing a 1:1 mapping between message/ohttp-req and message/bhttp, but we don't have any cryptographic enforcement of this pairing. If someone were to reuse the encapsulation mechanism in this document with another message type, say, to encapsulate application/dns-message values with a application/oblivious-dns-message wrapper, then we'd probably want to ensure that targets can't get confused between these two types. We could use the HPKE info string to separate these two protocols. (This is related to .)
The encapsulated payload could be something other than HTTP. We should be clear about our decision to do that and how alternative payloads might be carried if people wanted to do that.
The clear example here would be allowing just a DNS message body. As long as the client and target agreed, they could use that without the proxy knowing. We could just loosen the restrictions on what the body is, or we could use different content types (if you want the proxy to know what it is?).
I think that the way you would do that is to define a new media type for DNS and then just go for it. (Of course, you need to debate whether to include a length field and a transaction ID field.) Maybe we don't need to do that in this draft, but we could explain how that might look.
I'd do the following here (in line with ): Replace as the HPKE info string with the content-type of the inner message, be it or . That way, both client and target must agree on the type of encapsulated payload to actually use it. Thoughts?
That might work. We have "ohttp response" as the label for HKDF expansion on the response. What would you include there? Maybe you should just extend with "message/bhttp request" and "message/bhttp response" and then the swapping in the media type becomes trivial.
Yeah, that's what I had in mind.
Sorry about that. Misremembered how this worked; I should have double-checked.
Change:
ESNI keys, or if a deployment of ESNI must be rolled back on the server. <del> The retry mechanism repairs most such inconsistencies.  If server and advertised keys mismatch, the server will respond with esni_retry_requested.  If the server does not understand the "encrypted_server_name" extension at all, it will ignore it as required by RFC8446; Section 4.1.2.  Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described in handle-server-response. </del> <ins> The retry mechanism repairs inconsistencies, provided the server is authoritative for the public name.  If server and advertised keys mismatch, the server will respond with esni_retry_requested.  If the server does not understand the "encrypted_server_name" extension at all, it will ignore it as required by RFC8446; Section 4.1.2. Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described in handle-server-response. </ins> Unless ESNI is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to

Discussion:
(WG email coming shortly.) Update: This has been rebased to master, now that is merged. The new server behavior ("Improve ESNI robustness") means clients can send GREASE ESNI extensions without interop issues. Write some text recommending this, better meeting the "Do not stick out" criteria.
The GREASE section seems fine to me. (NAME is there other new material in this PR?) NAME NAME please have a look when possible.
It's whatever's in the second commit, so mostly that section but also a bit elsewhere: URL
I share the view that the GREASE section looks fine.
NAME Did you mean to leave the comments on URL (Notably the text already has seen a number of revisions here. I haven't gone back to update this PR yet. This PR was meant to just be the second commit.)
Ugh. Having something which claims to be a merged PR is kind of an attractive nusiance, then, no? Perhaps you can apply the changes here?
In my defense, I split them at your request and did include the following. ;-) But, sure, I can rebase this one. I figured was the bulk of the interesting bits (7401f55013f68ec47dad36b99977ad6aa881d9f1 is much smaller) so I figured we'd first and then I'd update this one at the end.
Sure, and I read that as "this is an accurate reflection of my put for both of these". But, sure, I can rebase this one. I figured Thanks.
Well, it was when I wrote that sentence. :-) Anyway, it's now been rebased and I've incorporated your comments as well.
Change:
Issuer name, identifying the Issuer.  This is typically a host name that can be used to construct HTTP requests to the Issuer. <del> Issuer Public Key pkI, with a key identifier "key_id" computed as described in issuer-configuration. </del> <ins> Issuer Public Key pkI, with a key identifier "token_key_id" computed as described in issuer-configuration. </ins> Challenge value "challenge", an opaque byte string.  For example, this might be provided by the redemption protocol in HTTP-

Discussion:
cc NAME NAME
Let's use different names to make this distinction clear.
This helps, thanks!
Change:
When decoding, values using more bits than necessary MUST be treated as malformed. <del> This means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values respectively. </del> <ins> This means that integers are encoded on 1, 2, or 4 bytes and can encode 6-, 14-, or 30-bit values respectively. </ins> <del> For example, the eight-byte sequence c2 19 7c 5e ff 14 e8 8c (in hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). </del> <ins> Vectors that start with "11" prefix are invalid and MUST be rejected. For example, the four byte sequence 0x9d7f3e7d decodes to 494878333; the two byte sequence 0x7bbd decodes to 15293; and the single byte 0x25 decodes to 37. </ins> The following figure adapts the pseudocode provided in RFC9000 to add a check for minimum-length encoding: The use of variable-size integers for vector lengths allows vectors <del> to grow very large, up to 2^62 bytes.  Implementations should take </del> <ins> to grow very large, up to 2^30 bytes.  Implementations should take </ins> care not to allow vectors to overflow available storage.  To facilitate debugging of potential interoperatbility problems, implementations should provide a clear error when such an overflow

Discussion:
The recently introduced variable size encoding allows for very large message sizes that are not practical in any realistic scenario. Since decoders will most likely not allow such large messages anyway, this PR limits the maximum size to 30-bit.
cc NAME who had some thoughts about limits on the last virtual interim.
My general points are: Code defensively Fail gracefully Use the lower level protocol carrying MLS Messages to send a clear and relevant error message if something is too big. Ex: HTTP/2.0 413 Commit.Proposals exceeds 2^16 bytes ex: HTTP/2.0 413 Too many proposals referenced in Commit (>9999)
Change:
as well; see collect-flow.)  In addition, the leader SHOULD abort the upload protocol and alert the client with error "reportTooLate". <del> The leader MUST buffer reports while waiting to aggregate them.  The </del> <ins> Leaders can buffer reports while waiting to aggregate them.  The </ins> leader SHOULD NOT accept reports whose timestamps are too far in the future.  Implementors MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew.  If the leader

Discussion:
Per NAME
NAME observes that we have an awkward MUST requirement on leaders buffering received reports: URL