jiebi/CodeConvo huggingface dataset:
Code change:
local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is <del> also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </del> <ins> also locally supported, as discussed in RFC3264, Sections 6.1 and 7, and start transmitting RTP media using that format once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </ins> specified in RFC7160, Section 3.1. The payload type mapping from the remote description is used to

Related discussion:
text: LGTM and if Justin wants to tie in the stuff from my comment a bit more that is great
NAME PTAL
seems like it's generally right,LGTM
Code change:
of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. <ins> A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and receiving some sort of answer".  Similarly, an imputed definition of "resolution" might be "the answer received from resolving". </ins> A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function.  Stub resolvers are discussed but

Related discussion:
text: …empt to define "resolve" and "resolution".
This issue concerns consistency and definition of some terms in the document. "Name server", "name server" and, perhaps, "server" seem to be used interchangeably. None of those terms have a formal definition in the document. The terms are also used in conjunction with various modifiers like "authoritative server", "DNS server", etc. While all those terms are likely pretty well-known, for the purposes of this document, un my opinion, it would be helpful to give a generic definition of "server", and how it is then combined with modifiers to form terminology for specific types of servers. Based on the definition of "server", it would be helpful to include a definition for "name server", "name server" or "DNS server" (pick one) and then use that term uniformly throughout the document.
Added a note about this in URL
Fixed in
These are common terms that are used in contexts that are not always associated with the resolver itself, so they should have stand-alone definitions.
First attempt at definition in URL
Code change:
Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. <del> The following Message Context Parameters are supported: </del> <ins> The following Message Properties are supported: </ins> 7.3.1.

Related discussion:
text: Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM
Code change:
representation of the challenge with the response object provided by the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. <del> The server provides a 200 (OK) response with the updated challenge object as its body. </del> <ins> Note that the challenges in this document do not define any response fields, but future specifications might define them.  The server provides a 200 (OK) response with the updated challenge object as its body. </ins> If the client's response is invalid for any reason or does not provide the server with appropriate information to validate the

Related discussion:
text: Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:
Code change:
None <del> 8.4. </del> <ins> 7.4. </ins> This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.

Related discussion:
text: When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.
Code change:
also ignores a Version Negotiation packet that contains incorrect connection ID fields; see QUIC-INVARIANTS. <del> Upon receiving the Version Negotiation packet, the client will search for a version it supports in the list provided by the server.  If it doesn't find one, it aborts the connection attempt.  Otherwise, it selects a mutually supported version and sends a new first flight with that version - this version is now the negotiated version. </del> <ins> Upon receiving the Version Negotiation packet, the client SHALL search for a version it supports in the list provided by the server. If it doesn't find one, it SHALL abort the connection attempt. Otherwise, it SHALL select a mutually supported version and sends a new first flight with that version - this version is now the negotiated version. </ins> The new first flight will allow the endpoints to establish a connection using the negotiated version.  The handshake of the

Related discussion:
text: in my 1st scenario, the server initiates incompatible version negotiation, the server selects D instead of C as chosen by client. The expectation here is that D will be the final negotiated version, and the version negotiation will end. But is there anything stopping the client to try to enforce it's chosen one (C) again? shall we have some to avoid this case? in the 2nd scenario, it is not possible if A, B, C,D, E,F all are compatible. if the server starts incompatible version negotiation with (C,D) and client does not find any supported version, it aborts the connection. I just realized - there is no normative text for aborting the connection attempt.. As the server expresses all the versions it support in the supported versions list, the client knows there is not point on continuing with another attempt with (E,F). Unless I am mistaken there is nothing now prohibiting the client to do so. It can continue to do so.
That doesn't make sense. The server initiates incompatible version negotiation by sending a VN packet, there's no notion of chosen version in the VN packet. There's no need for normative text when there's nothing else a client can do, are you saying the client could do something wrong as opposed to aborting due to lack of versions? The client will ignore any VN packet apart from the first one:
right, my bad. I think I have drawn the picture wrong. Server send (D,C) and the client choses C but the server choses D. does this make sense? and the main issue goes away? sniped from my previous comment. >The expectation here is that D will be the final negotiated version, and the version negotiation will end. But is there anything stopping the client to try to enforce it's chosen one (C) again? shall we have some to avoid this case? yes . and should we try to prevent it? OK, I see the client ignores, but what does happen then ? does it abort the connection attempt ? Is it possible for the client to start another connection attempt with complete new original versions and a new set of other versions?
Zahed and I discussed this first scenario offline.
Code change:
also ignores a Version Negotiation packet that contains incorrect connection ID fields; see QUIC-INVARIANTS. <del> Upon receiving the Version Negotiation packet, the client will search for a version it supports in the list provided by the server.  If it doesn't find one, it aborts the connection attempt.  Otherwise, it selects a mutually supported version and sends a new first flight with that version - this version is now the negotiated version. </del> <ins> Upon receiving the Version Negotiation packet, the client SHALL search for a version it supports in the list provided by the server. If it doesn't find one, it SHALL abort the connection attempt. Otherwise, it SHALL select a mutually supported version and sends a new first flight with that version - this version is now the negotiated version. </ins> The new first flight will allow the endpoints to establish a connection using the negotiated version.  The handshake of the

Related discussion:
text: In this scenario, the client indicated that it was happy with D by sending it in its Other Versions, so the client will be happy when D is negotiated even if it preferred C. If the client didn't like D, it could have removed D from Other Versions and then the connection would have negotiated C. Fair enough, this can be fixed with a small tweak - see below. Zahed and I discussed this second scenario offline as well. I wrote up to make the incompatible VN text more normative and that addresses Zahed's concern here. Now we have normative text to guarantee a failure in that scenario. If the client wants to start a separate connection attempt later, it will restart the algorithm from the top. We explicitly decided as a WG to avoid telling the client to remember information from previous connection attempts because VN packets don't carry an expiration date so caching them is fraught.
LGTM
Code change:
Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length <del> of the plaintext. </del> <ins> of PLAINTEXT_2. </ins> <del> CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2 </del> <ins> CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 </ins> Encode message_2 as a sequence of CBOR encoded data items as specified in asym-msg2-form.

Related discussion:
text: There has been a lot of suggestions and discussion regarding the key derivation latelely. Below is an attempt to summarize all the current suggstions that currently seems relatively likely to be done. This is not an issue in itself but I think it is good to have somewhere to discucess the complete changes to the key derivation. Suggested to permute the order of element in the TH2 sequence to be more resistant to any future collision attacks in hash functions. Exact order unclear but suggested to put the random and unpredictable GY first. Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes to simplify formal verification. Endpoints agree on that they received the same plaintext rather then the same cipertext.Suggested to use a salt derived from PRK in Extract to avoid usign the PRK keys directly in both Extract and ExpandSuggested to use unsigned integer instead of text string for label to save memory.Suggestion to add a final key derivation PRKout and use that in the exporter. Note that the exporter would also have uint labelsSuggestion to base Key-Update on Expand instead of extract. The label would need IANA registration. hashlength is a new variable that the implementation needs to keep track of. Should considered whether using Exporter for KeyUpdate has any disadvantages. Suggested that more info on how an application protocol is supposed to use KeyUpdate and Exporter together is needed.The EDHOC internal key derivations (i.e., not using the Exporter) would then be something like below. The exact labels should be discussed. Note that that only some of the derivations actually need a label to avoid collisionIncluding KeyUpdate, the IANA registered exporter labels could be:
Looks good. I had different naming in mind of the salts: PRK3e2m = Extract( SALT3e2m, GRX ) PRK3m = Extract( SALT3m, GIY ) where SALT3e2m = EDHOC-KDF( PRK2e, TH2, 0, h'', hashlength ) SALT3m = EDHOC-KDF( PRK3e2m, TH3, 0, h'', hashlength ) With this the salts are named by its use rather than from what key they are derived.
The labels was just to illustrate the fact that they don't need to be separate.
Code change:
Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length <del> of the plaintext. </del> <ins> of PLAINTEXT_2. </ins> <del> CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2 </del> <ins> CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 </ins> Encode message_2 as a sequence of CBOR encoded data items as specified in asym-msg2-form.

Related discussion:
text: I think it is still better to just use 0-7. That makes it very easy for the reader to see that there are no collisions.
NAME Was this a comment on my proposed names of salts, or a separate comment? (I agree labels 0-7 is good.)
It was a separate comments. Your suggestion for salt naming is fine with me. Some other non-technical naming things that a hidden in my summary above I think keylength should use different terms in the derivation of K4 and OSCORE Master Secret. The current naming gives the idea that they are the same. I think the contexts in the MAC2 and MAC3 derivations should be given names. Should consider collection all the EDHOC-KDF derivations in a single place.
Might want to derive: K4 = EDHOC-KDF( PRK3m, TH4, 0, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 0, h'', ivlength ) to avoid that the applicaiton gets K4 and IV4. Another alternative is to use K4 = EDHOC-Exporter( 7, h'', keylength ) IV4 = EDHOC-Exporter( 8, h'', ivlength ) and forbid the application to use the labels for K4 and IV4
Editorial; should be: K4 = EDHOC-KDF( PRK3m, TH4, 1, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 2, h'', ivlength ) or, if we want all KDF labels distinct: K4 = EDHOC-KDF( PRK3m, TH4, 8, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 9, h'', ivlength ) Alternatively, application access to Exporter only allows uint with: K4 = EDHOC-Exporter( -1, h'', keylength ) IV4 = EDHOC-Exporter( -2, h'', ivlength )
Trying to compile the suggestions.
Code change:
Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length <del> of the plaintext. </del> <ins> of PLAINTEXT_2. </ins> <del> CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2 </del> <ins> CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 </ins> Encode message_2 as a sequence of CBOR encoded data items as specified in asym-msg2-form.

Related discussion:
text: These have a PR: Suggested to permute the order of element in the TH2 sequence … Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes … Suggestion to add a final key derivation PRKout and use that in the exporter The following needs to be addressed: Suggested to use a salt derived from PRK in Extract define salt derive salt Suggested to use unsigned integer instead of text string for label to save memory suggestion to base Key-Update on Expand consider whether using Exporter for KeyUpdate has any disadvantages. more info on how an application protocol is supposed to use KeyUpdate and Exporter together distinguish keylength in K3/K_4 and OSCORE Master Secret define contexts explicitly table of KDF derivations
Trying to put things together. Let's call this variant A, part 1. where and (edit: depending on method) New salts to avoid double use of PRK, named by its use. Same construction for K4/IV4 as K3/IV3, motivating the renaming of 3m in as 4e3m. The label in the KDF, third argument, is an uint, all distinct for simplicity.
Variant A, part 2: Distinct "transcript hash" in KeyUpdate and Exporter. Exporter does not give access to EDHOC internal keys. OSCORE key length separate from key_length. Edit: Not clear that 'context' is needed in the EDHOC-Exporter. Also, to be strict in labelling we could continue enumeration. Here is variant B, part 2 (B.1 = A.1):
Variant C.2 (C.1 = A.1): (edited:) Same as B.2 but with different labels. With variant C we have essentially: the internal KDF labels with current list: 0, ..., 9; and the IANA EDHOC Exporter Registry with current list: 0, 1.
NAME NAME NAME and all: Any implementation considerations or other comments on variant C above? We'll start with the PR(s) soon.
The last posts here are confusing.... I don't agree. These are separate. We should definitly not try to keep them separate. I.e.
Code change:
Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length <del> of the plaintext. </del> <ins> of PLAINTEXT_2. </ins> <del> CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2 </del> <ins> CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 </ins> Encode message_2 as a sequence of CBOR encoded data items as specified in asym-msg2-form.

Related discussion:
text: it should be Master Secret = EDHOC-Exporter( 0, h'', oscorekeylength ) Master Salt = EDHOC-Exporter( 1, h'', oscoresaltlength )
The above looks good to me with the following not so interesting options. order of the 0-9 labels use 10 or 0 label for Key-Update order of the h'00' and h'01' "transcripts"
I think we should maybe merge the "context" and "transcript hash" inputs. This simplifies things and avoids using h'00' and h''01' as "transcript hashes.
Alternatively
The latest version of the summary URL looks good.
Overview of main changes needed: Merge Rename PRK3m as PRK4e3m Section 4.1 update PRK definitions move section PRKout to 4.2 Section 4.2 Update EDHOC-KDF and info definition Update derivations Include derivations of salts and K4 / IV4 List EDHOC-KDF derivations with labels 0-9 Section 4.3 Update EDHOC-Exporter (use label 10 instead of 11) Remove derivation of K4 / IV4 Section 4.4 Update EDHOC-KeyUpdate (use label 11 instead of 10) Section 5.3.2 Define context2 Section 5.4.2 Define context3 Section 9.1 Update EDHOC Exporter labels Appendix A.1 Update Master Secret/Salt derivation
Additional updates: As noted in previous comment, a proposal to interchange labels 10 and 11 to enumerate labels in the order they appear in the specification. (Other proposal for assignment of integer labels is welcome.) Should we align / adapt definition of contextx and externalaad? Currently (for message2 and similar for message3): externalaad = > context2 = > Edit: Seems to be favourable to at least align this blobs, so changed context2 to > and similar for context_3, in 5464707a
PRKexporter is a key which we only introduce for simple distinction between different KDF applications. Perhaps an overkill? May open up for unnecessary discussion about properties of that key. Here is another variant: Edit: As commented before, Marco thinks a separate PRKExporter is preferred; less error prone etc.
Code change:
Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length <del> of the plaintext. </del> <ins> of PLAINTEXT_2. </ins> <del> CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2 </del> <ins> CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 </ins> Encode message_2 as a sequence of CBOR encoded data items as specified in asym-msg2-form.

Related discussion:
text: Most old comments are now addressed, and there are quite a few changes, so it is a good time to merge PR . Remaining points: derivation of K4/ IV4 and text about key confirmation. Not clear if there is any difference in practice between K4 /IV4 being derived from PRK4e3m or PRKout, but the current text about explicit key confirmation is not valid in the former case. May alternatively tune down the key confirmation terminology. Suggested to make clearer distinction between key derivation for EDHOC processing, resulting in PRKout, and key derivation for application, i.e. making use of PRKout in EDHOC-Exporter and EDHOC-KeyUpdate. More guidance on the latter is also proposed.
Tried to address the remaining points in the previous comment with the latest two commits: 5d675ac and 95e35bb. More guidance on KeyUpdate may still be needed. Other points?
NAME What more guidance is needed on KeyUpdate?
Was a request from someone. Might be hard to understand how to use it. E.g. that you should alternate key update and exporter Exporter Key Update Exporter Key Update Exporter ...
Another guidance needed is how to manage overwrite of PRKout pending confirmation of the derived key from the other endpoint. When the Initiator is updating PRKout it needs both old and new derived keys to be able to communicate securely in lock-step the change to the new key.
Perhaps good to remark that the entire application contexts (including e.g. sequence numbers) need to be maintained before a transition is made.
see instead. The current discussion has very little to do with
Code change:
that care about timing; the ability to provide control of reliability, choosing which <del> messages to retransmit in the event of packet loss, and how best to make use of the data that arrived; </del> <ins> messages to retransmit when there is packet loss, and how best to make use of the data that arrived; </ins> the ability to manage dependencies between messages, when the transport system could decide to not deliver a message, either

Related discussion:
text: Closed
I just read Arch and have the following NiTs which I think we should address: /Listeners by default register with multiple paths/ ought this to be: /Listeners, by default, register with multiple paths/ /A Framer is a data translation layer that can be added to a Connection to define how application-level Messages are transmitted over a transport protocol. / I think this should be (because I don’t think they are protocol specific) /A Framer is a data translation layer that can be added to a Connection to define how application-level Messages are transmitted over the transport service. / /to retransmit in the event of packet loss,/ better to avoid event here :-) /to retransmit when there is packet loss,/
I am just gonna add a few more nits here: The Listener object in figure 4 is a bit awkward, it appears as if the Listen() call appears out of thin air while per the API it gets called on the preconnection object like Initiate() and Rendezvous(). In section 4.1.1, there are 5 references to section 4.1.2, is it really necessary to have that many? Point 2 in section 4.2.3 only talks about required transport services, the same should probably be said about prohibited services, i.e. "both protocol stacks MUST NOT offer transport services prohibited by the application"
Let me add to this: Section 1: print send() and recv() in fixed-with font [HTML/XML issue only] Section 2 - Figure 1: socket() [with the brackets] looks odd in the figure title
NAME I fear framers may be specific to the underlaying protocol, e.g., for SIP slicing messages out of TCP stream whereby doing nothing for SCTP and UDP
In relation to frames I think I only asked to add /service/ instead of protocol... I don't understand how Phil's comment reacts to that
NAME I think protocol is correct here and would not change the sentence.
OK - so I think you are saying the framer depends only on the specific next protocol, rather than upon the transport service that was offered? - It is still not clear to me that this is correct.
NAME that is a fairly good question… The behaviour of the framer defiantly depends on the transport service provided (which may be a subset or superset of the transport service requested).