jiebi/CodeConvo huggingface dataset:
Change:
The string "reg", indicating an update to the registration. <del> The JWK thumbprint of the old key RFC7638, base64url-encoded </del> <ins> The JWK thumbprint of the new key RFC7638, base64url-encoded </ins> <del> The client signs this object with the new key pair and encodes the </del> <ins> The client signs this object with the old key pair and encodes the </ins> object and signature as a JWS.  The client then sends this JWS to the <del> server in the "newKey" field of a request to update the registration. </del> <ins> server in the "rollover" field of a request to update the registration. </ins> <del> On receiving a request to the registration URL with the "newKey" </del> <ins> On receiving a request to the registration URL with the "rollover" </ins> attribute set, the server MUST perform the following steps: <del> Check that the contents of the "newKey" attribute are a valid JWS </del> <ins> Check that the contents of the "rollover" attribute are a valid JWS </ins> <del> Check that the "newKey" JWS verifies using the key in the "jwk" header parameter of the JWS </del> <ins> Check that the "rollover" JWS verifies using the account key correspdonding to this registration </ins> Check that the payload of the JWS is a valid JSON object Check that the "resource" field of the object has the value "reg" <del> Check that the "oldKey" field of the object contains the JWK thumbprint of the account key for this registration </del> <ins> Check that the "newKey" field of the object contains the JWK thumbprint of the account key used to sign the request </ins> If all of these checks pass, then the server updates the registration by replacing the old account key with the public key carried in the <del> "jwk" header parameter of the "newKey" JWS object. </del> <ins> "jwk" header of the request JWS. </ins> If the update was successful, then the server sends a response with status code 200 (OK) and the updated registration object as its body.

Discussion:
As discussed in the thread about , we can have a fairly clean recovery story (assuming a MAC key can be provisioned. As a first step, we should reverse the order of the signatures in the roll-over request object. Just wanted to make sure everyone is aware that there's an ACME F2F meeting happening at the IETF this afternoon, 17:40-19:40 Argentina Time (13:40-15:40 US Pacific, 20:40-22:40 UTC). URL Remote participation is possible. You can find links to audio streaming, XMPP chat, and a MeetEcho room in ACME line on the above agenda page. See you there! --Richard
Change:
MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> Extensions MAY define a different mechanism to negotiate the presence of contexts, and they MAY do so in a way which is opaque to </del> <ins> Extensions MAY define a different mechanism to communicate whether contexts are in use, and they MAY do so in a way which is opaque to </ins> intermediaries. 4.4.3.

Discussion:
It doesn't appear that the peer has any say in the allocation of context IDs. If not, they're not really "negotiated." Perhaps better to say that they are "declared" or merge with "allocated."
Change:
using the public key from the credential stored at the leaf in the tree indicated by the "sender" field. <del> Verify that all PSKs specified in any PreSharedKey proposals in the "proposals" vector are available. </del> <ins> Verify that all PreSharedKey proposals in the "proposals" vector have unique PreSharedKeyIDs and are available. </ins> Generate the provisional ratchet tree and GroupContext by applying the proposals referenced in the initial Commit object, as

Discussion:
As discussed in , PreSharedKeyIDs shouldn't be repeated in the same commit
Should multiple PSK proposals within a commit be able to reference the same ? I feel like this should be covered in the same way we state multiple removals for the same should result in the committer choosing one. Wasn't sure if this was an oversight or on purpose. I can submit a PR to clarify if this is something that should be addressed
I agree, duplicates are an error. Committer MUST NOT include duplicates; receiver MUST reject Commit with duplicates. NAME - Please send a PR!
Change:
the UCCS through the Secure Channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example, using a <del> Detached EAT Bundle (I-D.ietf-rats-eat). </del> <ins> Detached-Submodule-Digest or Detached EAT Bundle (I-D.ietf-rats-eat). </ins> 4.3.

Discussion:
Archived-At:
straight forward. :ship: it! A few comments/questions for WGLC: The secure channel definition in section 1.1 may benefit from stating that mutual authentication is not required. This is hinted at by stating "the same qualities" as CWT conveyance are required but, given the NIST definition requires mutual auth, additionally saying mutual auth is not required would be clearer.In section 3.1.2, perhaps change the end of the last sentence to "using a Detached-Submodule-Digest or Detached-EAT-Bundle" since the Detached-Submodule-Digest is what conveys the hash and can be used independent of a Detached-EAT-Bundle.In Table 1 in Section 4, should the Data Item be Claims-Set instead of map? The registry is inconsistent. Some definitions are general with only map or array listed, others identify a specific type, e.g., the COSE types.There is a TODO in Appendix A and a note to insert definitions from 9052.The CDDL should include the tag definition that is the focus of this draft, something like: UCCS = .TBD601(Claims-Set) Independent of this draft, many current specs that use CDDL (including this one) repeat definitions that appear elsewhere. Perhaps it is close to time to discontinue this practice, publish an I-D or two that provide CDDL definitions for specs that predate CDDL (like RFC5911 and 5912 did for ASN.1), and then have future specs only define new things. On 1/11/23, 1:27 PM, "RATS on behalf of Henk Birkholz" on behalf of EMAIL > wrote: Dear RATS WG, this I-D should now be ready for WGLC. Viele Grüße, Henk RATS mailing list EMAIL URL
Change:
4.1.4. <del> [TODO] </del> <ins> The createDataChannel method creates a data channel and attaches it to the PeerConnection.  If no data channel currently exists for this PeerConnection, then a new offer/answer exchange is required.  All data channels on a given PeerConnection share the same SCTP/DTLS association and therefore the same m= section, so subsequent creation of data channels does not have any impact on the JSEP state. The createDataChannel method also includes a number of arguments which are used by the PeerConnection (e.g., maxPacketLifetime) but are not reflected in the SDP and do not affect the JSEP state. </ins> 4.1.5.

Discussion:
NAME See above
LGTM when outstanding comment addressed
JSEP currently has this: createDataChannel [TODO] We need this text before WGLC, so it's being added to the punchlist.
Change:
2.7.2.2. <del> A descendant segment produces zero or more descendants of the input </del> <ins> A descendant segment produces zero or more descendants of an input </ins> value. <del> A descendant selector visits the input value and each of its descendants such that: </del> <ins> For each node in the input nodelist, a descendant selector visits the input node and each of its descendants such that: </ins> nodes of any array are visited in array order, and

Discussion:
Add clarifications that the input nodelist provides the outer order, the segments provide a middle-level order, and selectors (if multiple) provide the inner order. This may have been obvious to some readers, but now should be obvious to more, including yours truly.
I don't think the example for in Table 17 is right. URL It says: It should be: Note that the descendants list puts out before and . The wildcard selector then has no choice but outputting , , , .
Nice catch! The example needs fixing as does the ordering note below Table 17.
I let the computer do the catching :-) Do you want to make these changes? I'd do a new issue then. (And wait a bit for Greg to catch up.)
NAME Yes, I'm happy to do that and please do create a new issue. I won't be able to fix it before the weekend at the earliest though.
URL
LGTM thanks. Semantics unchanged, but hopefully a lot clearer.
Change:
MUST return a 405 Method Not Allowed response for any HTTP PATCH request. <del> A WHIP resource receving a PATH request with new ICE candidates, but which does not perform an ICE restart, MUST return a 204 No content response without body. </del> <ins> A WHIP resource receiving a PATCH request with new ICE candidates, but which does not perform an ICE restart, MUST return a 204 No content response without body. </ins> If the HTTP PATCH request results in an ICE restart, the WHIP resource SHALL return a 200 OK with an "application/trickle-ice- sdpfrag" body containing the new ICE username fragment and password <del> and, optionaly, the new set of ICE candidates for the media server. </del> <ins> and, optionally, the new set of ICE candidates for the media server. </ins> As the HTTP PATCH request sent by a WHIP client may be received out of order by the WHIP resource, the WHIP resource SHOULD keep track of

Discussion:
If you find them useful, here are some spelling fixes. The ' PATH ' spelling is confusing, I think it should be ' PATCH ' Also the draft URL points to and older draft. I have been very inspired by WHIP, thank you for giving it to the community.
Change:
first bit of the Options field.  Three values are reserved for special constructs: <del> An 8-bit unsigned integer follows the initial byte and indicates the length of options/payload minus 13. </del> <ins> An 8-bit unsigned integer (Extended Length) follows the initial byte and indicates the length of options/payload minus 13. </ins> <del> A 16-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 269. </del> <ins> A 16-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 269. </ins> <del> A 32-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 65805. </del> <ins> A 32-bit unsigned integer (Extended Length) in network byte order follows the initial byte and indicates the length of options/payload minus 65805. </ins> <del> The encoding of the Len field is modeled on CoAP Options (see section 3.1 of RFC7252). </del> <ins> The encoding of the Length field is modeled on CoAP Options (see section 3.1 of RFC7252). </ins> <del> The following figures show the shim headers for the 0-bit, 16-bit, and the 32-bit headers. </del> <ins> The following figures show the message format for the 0-bit, 16-bit, and the 32-bit variable length cases. </ins> For example: A CoAP message just containing a 2.03 code with the token 7f and no options or payload would be encoded as shown in fig-

Discussion:
These labels are confusing and should be rewritten more in the style of RFC6455 with "Length" and "Extended Length" for clarity.
And remember to replace the last reference to: The following figures show the shim headers for the 0-bit, 16-bit, and the 32-bit headers.
Change:
For example, an X.509 certificate is provided as its direct binary serialization.  If C509 certificates or CWTs are used as authentication credentials, each is provided as the binary <del> serialization of a (possibly tagged) CBOR array.  If CCSs are used as authentication credentials, each is provided as the binary serialization of a CBOR map. </del> <ins> serialization of a (possibly tagged) CBOR array.  If CWT Claims Sets are used as authentication credentials, each is provided as the binary serialization of a CBOR map. </ins> If authentication credentials are CWTs, then the untagged CWT associated with an entity is stored in the Security Context and used

Discussion:
So far, it was used 1x in abbreviated form, and 2x as "CWT Claims Sets (CCS)". The abbreviation was problematic the way it was used while being a reference into RFC8392, it was not defined there. I'm not 100% happy with dropping the term "CCS" because it having an abbreviation is a good pointer for users to see that this is an established, good and compact thing to use (right?), but I'd rather spare readers the confusion of clicking through to 8392 and not finding the letters "CCS". I'd be happy with any better handling of the possible confusion, this is just the best I'm coming up with.
Change:
In addition, for each PDAParam instance, leaders are required to: <del> Ensure that, for each report, all aggregator shares are either included or not in a given batch; </del> Implement and store state for the form of inter- and intra-batch replay mitigation in anti-replay; and

Discussion:
I also deleted a bunch of the (outdated) system design text. I'm sure this can be simplified, but I think this captures the basic assumptions (at least in my mental model).
Indeed, the text doesn't require any specific mitigation, and I don't see why it should. Aggregators could do the thing described in the appendix, or they could keep a huge list of all reports seen thus far. There could even be some simpler variant in the future I don't think we lose anything by eliding the implementation details here.
Change:
Connectionless transports, it occurs when the first Message is received from the Remote Endpoint.  The resulting Connection is contained within the RendezvousDone<> Event, and is ready to use as <del> soon as it is passed to the application via the Event. </del> <ins> soon as it is passed to the application via the Event.  Changes made to a Preconnection after Rendezvous() has been called do not have any effect on existing Connections. </ins> An EstablishmentError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for rendezvous or cannot be reconciled with the Local and/or Remote Endpoints, when the Local Endpoint or Remote Endpoint cannot be resolved, when no transport-layer connection can be established to the Remote Endpoint, <del> or when the application is prohibited from rendezvous by policy. When using some NAT traversal protocols, e.g., Interactive Connectivity Establishment (ICE) RFC5245, it is expected that the Local Endpoint will be configured with some method of discovering NAT bindings, e.g., a Session Traversal Utilities for NAT (STUN) server. In this case, the Local Endpoint may resolve to a mixture of local and server reflexive addresses.  The Resolve() action on the Preconnection can be used to discover these bindings: The Resolve() call returns a list of Preconnection Objects, that represent the concrete addresses, local and server reflexive, on which a Rendezvous() for the Preconnection will listen for incoming Connections.  These resolved Preconnections will share all other Properties with the Preconnection from which they are derived, though some Properties may be made more-specific by the resolution process. This list can be passed to a peer via a signalling protocol, such as SIP RFC3261 or WebRTC RFC7478, to configure the remote endpoint. </del> <ins> or when the application is prohibited from rendezvous by policy: </ins> 6.4.

Discussion:
In §6.3 we have: This doesn't work, because takes only a single . The action on a should rather be on a or .
Change:
a signer (either the private key associated with the certificate, or interface to perform private key operation) for each chain <del> an optional authenticator request </del> <ins> an optional authenticator request or certificate_request_context (from 0 to 255 bytes) </ins> It returns the exported authenticator as a sequence of octets.  It is RECOMMENDED that the logic for selecting the certificates and

Discussion:
Make it possible to choose a non-empty certificaterequestcontext when there is no authenticator request. This change introduces the flexibility needed to achieve compound authentication between certificates using a technique called CRC Smuggling, described by Jonathan Hoyland.
Change:
Person & email address to contact for further information: iesg@ietf.org <ins> 3.2. This specification defines a new "Function Extensions sub-registry" in a new "JSONPath Parameters registry", with the policy "expert review" (BCP26). The experts are instructed to be frugal in the allocation of function extension names that are suggestive of generally applicable semantics, keeping them in reserve for functions that are likely to enjoy wide use and can make good use of their conciseness.  The expert is also instructed to direct the registrant to provide a specification (BCP26), but can make exceptions, for instance when a specification is not available at the time of registration but is likely forthcoming.  If the expert becomes aware of function extensions that are deployed and in use, they may also initiate a registration on their own if they deem such a registration can avert potential future collisions. Each entry in the registry must include: Initial entries in this sub-registry are as listed in pre-reg: </ins> 4. Security considerations for JSONPath can stem from

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:
2. <del> This section uses the concept of ICE agent as define in RFC8445.  In the remainder of the document, it is assumed that each browser execution context has its own ICE agent. </del> <ins> This section uses the concept of ICE agent as defined in RFC8445.  In the remainder of the document, it is assumed that each browsing context (as defined in Section 7.1 of HTMLSpec) has its own ICE agent. </ins> 2.1. <del> For any host candidate gathered by an ICE agent as part of RFC8445 section 5.1.1, obfuscation of the candidate is done as follows: </del> <ins> For any host candidate gathered by an ICE agent as part of RFC8445, Section 5.1.1, the candidate is handled as follows: </ins> Check whether the ICE agent has a usable registered mDNS hostname <del> resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. If there is a registered hostname, replace the IP address of the ICE host candidate with the hostname.  Expose the candidate and abort these steps. </del> <ins> resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".

Discussion:
Followup from , as discussed today
Will wait for LGTM from NAME before merging.
Rethought my approach here and rewrote the section accordingly. PTAL.
LGTM
Sorry for the delay. Github did not let me see any diffs over the weekend.
Change:
PSK (a pre-shared key established externally or a resumption_master_secret value from a previous connection) <del> (EC)DHE shared secret </del> <ins> (EC)DHE shared secret (ecdhe-shared-secret-calculation) </ins> This produces a full key derivation schedule shown in the diagram below.  In this diagram, the following formatting conventions apply:

Discussion:
Exporters and (EC)DHE secrets are not traffic secrets. Group the two (EC)DHE sections under a name which matches what the key schedule section calls it (the "(EC)DHE shared secret") and link to it from the key schedule.
Change:
corresponding to the ciphersuite in use, as well as the credential under which the UserInitKey was signed <del> The update secret resulting from this change is an all-zero octet </del> <ins> The "update_secret" resulting from this change is an all-zero octet </ins> string of length Hash.length. After processing an Add message, the new member SHOULD send an Update

Discussion:
"The update secret resulting from this change is the path secret for the root node of the ratchet tree." is suspicious because in the derivation, the index for both the and is the same as the level of the node. It should be the "above the root" and not "for the root" (which is the one used to derive the of the root)...
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .