jiebi/CodeConvo huggingface dataset:
Code change:
4.2.2. The stopped property indicates whether the transceiver has been <del> stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </del> <ins> stopped, either by a call to stop or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </ins> A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.

Related discussion:
text: Several small updates: Issue 15: local media state, local resources correct, removed comment. - Issue 16: updated wording to use 'calling this method', removed comments, - Issue 17: changed stopTransceiver to stop, removed comments, - Issue 18: changed 'directional attribute' to 'direction attribute', removed comments,
LGTM once lands
18) [rfced] Section 4.2.5: We see "direction attribute" but not "directional attribute" in RFC 3264. Will this text be clear to readers? (We ask because we also see "A direction attribute, determined by applying the rules regarding the offered direction specified in [RFC3264], Section 6.1" in Section 5.3.1 of this document.) Original: More specifically, it indicates the [RFC3264] directional attribute of the associated m= section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer.
This should indeed be , as that's the terminology used by 3264.
NAME please close this issue once you consider it resolved.
17) [rfced] Section 4.2.2: Will "stopTransceiver" be clear to readers? We could not find this string elsewhere in this document, anywhere else in this cluster of documents, in any published RFC, or in google searches. Original: The stopped property indicates whether the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section.
This should be , rather than .
NAME please close this issue once you consider it resolved.
16) [rfced] Section 4.1.16: Should "The effects of this method call" be "The effects of calling this method," and should "This call" be "Calling this method"? Original: The effects of this method call depend on when it is invoked, and differ depending on which specific parameters are changed: ... This call may result in a change to the state of the ICE Agent.
SGTM
NAME please close this issue once you consider it resolved.
15) [rfced] Section 4.1.10: Please confirm that "local media state" and "local resources" (as opposed to remote) are correct in the context of setRemoteDescription.
Code change:
4.2.2. The stopped property indicates whether the transceiver has been <del> stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </del> <ins> stopped, either by a call to stop or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </ins> A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.

Related discussion:
text: (We ask because we see identical wording in Section 4.1.9 ("setLocalDescription").) Original: This API changes the local media state; among other things, it sets up local resources for sending and encoding media.
yes, this is correct
NAME please close this issue once you consider it resolved.
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right
Code change:
bhttp request", a zero byte, "key_id" as an 8-bit integer, plus "kem_id", "kdf_id", and "aead_id" as three 16-bit integers. <del> Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt". </del> <ins> Create a receiving HPKE context, "rctxt", by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info". </ins> Decrypt "ct" by invoking the "Open()" method on "rctxt" (HPKE), with an empty associated data "aad", yielding "request" or an

Related discussion:
text: Why is it that media type registration is a journey of discovery each and every time? It's like the coastline paradox: the closer you get, the more detail resolves. Also, each requirement makes sense in isolation, but if you need an entire RFC to explain it, maybe something has gone wrong.
no strong feelings on this one.
Code change:
Abstract This document provides an overview of the architecture of Transport <del> Services, a system for exposing the features of transport protocols to applications.  This architecture serves as a basis for Application Programming Interfaces (APIs) and implementations that provide flexible transport networking services.  It defines the common set of terminology and concepts to be used in more detailed discussion of Transport Services. </del> <ins> Services, a model for exposing transport protocol features to applications for network communication.  In contrast to what is provided by most existing Application Programming Interfaces (APIs), it is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams.  This document further defines the common set of terminology and concepts to be used in definitions of APIs and implementations. </ins> 1.

Related discussion:
text: Thanks for these fixes! I did a bit of reworking of the abstract, but it keeps the main part of the changes you made.
Regarding the sentence you removed, that was an adaption of an existing sentence, which I believe aimed to mention the words implementation and API to implicitly refere to the other docs (which was probably too subtle for anybody to notice anyway). However, the other change I made to that sentence was to mention one of the benefits / deployment incentives for taps (dynamic protocol and path selection). I wasn't sure about the wording here, but I think it would be good to (re-)add a sentence to the abstract saying why taps is so great and that everybody should deploy it.
Yes, the original second sentence was aimed at mentioning that there were two other documents, API and Implementation, that would be based on this one. I liked how in your revision, it did try to make things clearer than just saying "flexible transport networking services", but I felt that the specific example of dynamic path and protocol selection was a bit too specific for that one line. (I was chatting with NAME about this as I was editing, btw). My thought was that the list of features that you added in right after that, which go through the top-level bullet points of the advantages, do a more comprehensive job of summarizing the benefit.
Code change:
Queries: <del> The examples in tbl-wild show the "wildcard" selector in use by a child segment: </del> <ins> The examples in tbl-wild show the wildcard selector in use by a child segment: </ins> The example above with the query "$.o[*, *]" shows that the wildcard selector may produce nodelists in distinct orders each time it

Related discussion:
text: Use parentheses as an indication that something is a function. Also, don't confuse the reader by alluding to potential future alternatives to value(). Reviewers: is this an improvement? It's a draft PR for now until we decide the change is worthwhile.
I think we'll need to explain the () notation, which should be familiar to C programmers but not necessarily to people who grew up on other languages. I also think we have a few more examples that point to hypothetical functions, such as , , .
I don't think there's a great point at which to explain that notation and, based on your observation, I'm going off the idea.
NAME Let's see how pans out before taking the current PR any further. Once I remove the function parentheses, the two PRs are changing the same text.
would be the place.
NAME As you suggested, I introduced this in 1.1, but near the start since it's notation rather than terminology. I did a regexp search to find and fix the remaining examples (your list was complete). In doing so, I found the strange markup and removed the backticks since there was no good reason for them.
We could do the fun() explanation and completeness search in a separate PR.
Code change:
An AEAD encryption algorithm <ins> A signature algorithm </ins> The ciphersuite's Diffie-Hellman group is used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption. The ciphersuite must specify an algorithm "Derive-Key-Pair" that maps

Related discussion:
text: It seems like we have a few separable issues here: Whether we require a single signature scheme for the whole group Whether signature schemes are included in the ciphersuite Whether we have an MTI ciphersuite / signature algorithm What new ciphersuites should be defined, and what algorithms should go in them Let's discuss this at the interim and maybe break this PR into a few bits
Note that specification required registries imply that there is a designated expert pool. I will add some text to create one. The text is very similar to the TLS DE pool text from with some tweaks that, hopefully, address the misunderstandings uncovered during non-standards track registry requests. Note the process is: (assuming that the IESG eventually approves this draft) When the IESG approves this draft, the responsible AD assigns some DEs (like 2-3 suggested by the WG chairs). These DEs are in charge of all registrations regardless of whether the draft comes from the WG or elsewhere as all requests go to the MLS DEs mailing list.
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 7 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :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.
Code change:
An AEAD encryption algorithm <ins> A signature algorithm </ins> The ciphersuite's Diffie-Hellman group is used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption. The ciphersuite must specify an algorithm "Derive-Key-Pair" that maps

Related discussion:
text: :smiley: You can also .
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there were no stargazers. - - 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 .
This seems to accurately reflect the consensus we had at the last interim, and there's nothing I can't live with otherwise. I will probably file a follow-up to convert the Derive-Key-Pair operations to use HKDF directly, as discussed, avoiding the need for intermediate values or truncation of SHA-512.
Code change:
include padding.  As an Authentication Parameter ("auth-param" from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the <del> base64url string includes "=" characters.  This attribute MAY be </del> <ins> base64url string includes "=" characters.  This parameter MAY be </ins> omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism. <del> "max-age", an optional attribute that consists of the number of </del> <ins> "max-age", an optional parameter that consists of the number of </ins> seconds for which the challenge will be accepted by the origin. Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> The header field MAY also include the standard "realm" attribute, if desired.  Issuance protocols MAY require other attributes. </del> <ins> The header field MAY also include the standard "realm" parameter, if desired.  Issuance protocols MAY require other parameters.  Clients SHOULD ignore unknown parameters in challenges, except if otherwise specified by issuance protocols. </ins> As an example, the WWW-Authenticate header field could look like this:

Related discussion:
text: The document refers to authentication scheme attributes throughout; the term from HTTP is 'parameters'. Also, both the challenge and credentials definitions should say what to do with unrecognised parameters.
Code change:
the IP header can be obtained (GET_ECN.UDP(-Lite)). Calling "Close" on a UDP Connection (ABORT.UDP(-Lite)) releases <del> the local port reservation. </del> <ins> the local port reservation.  The Connection then issues a "Closed" event. </ins> Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close", except that the Connection will send <del> a ConnectionError Event rather than a Closed Event. </del> <ins> a "ConnectionError" Event rather than a "Closed" Event. </ins> Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all

Related discussion:
text: Takes care of item 5 and .
See discussion on
Provide a complete template that covers all functions/properties from the API. Indicate how the template should be used (e.g. leave out the parts that are not relevant for a particular protocol or include all fields and mark fields that are not relevant as such.
I'm wondering if this is really something that's in scope that we should cover. We do have the message properties section that explains how to implement various properties, but I think adding each property to every protocol mapping will be a huge amount of text that will be difficult to get exactly right.
I agree, we have added additional properties since we opened this issue to check the mapping and make sure we have a complete coverage. We should still be consistent in how we treat things though, and perhaps add a sentence that we do not describe all the properties for instance. I have made a pass through to check the mapping from the API to impl. draft for all the protocol mappings as a basis for making things consistent. Here is the summary. We cover the same actions and events for all the protocols with the exceptions that UDP Multicast does not cover the ConnectionError event and SCTP covers the Priority connection property. And MPTCP and UDP-lite are special as they refer back to the base protocols. There is one terminology inconsistency where the impl. draft refers to InitiateError and this has been generalized to EstablishmentError in the API Unless I missed something, there are only two actions that can be made on a connection that are not covered, addRemote and removeRemote. This is probably fine as they do not mean much for most of the protocols (or we could add them to be complete). We should perhaps mention how they relate to MPTCP though if we leave them out. We also do not cover the Preconnection.Rendezvous action. Again this may be fine as it is a bit special (or we can mention it for consistency.) For the events, we cover a subset with main focus on the connection related events. The Closed Event and some events related to connection setup are missing. As we cover ConnectionError we should perhaps cover the Closed event as well? We do not cover any of the Send or Receive events which seems fine.
Code change:
the IP header can be obtained (GET_ECN.UDP(-Lite)). Calling "Close" on a UDP Connection (ABORT.UDP(-Lite)) releases <del> the local port reservation. </del> <ins> the local port reservation.  The Connection then issues a "Closed" event. </ins> Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close", except that the Connection will send <del> a ConnectionError Event rather than a Closed Event. </del> <ins> a "ConnectionError" Event rather than a "Closed" Event. </ins> Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all

Related discussion:
text: In relation to Connection and Message properties, we do not cover any of them except for the Connection priority covered for SCTP and we talk about some properties in connection to UDP-lite and MPTCP. SCTP also has support for partial reliability and unordered messages so not sure why the priority part was singled out and added. NAME any particular reasoning behind this part? Possibly we should remove the priority part for SCTP or discuss it in running text in a similar fashion as for UDP-lite and MPTCP We may want to update the UDP-lite description to also say something about what properties it supports over UDP. The current description sounds like it is a subset. Once we agree on how to deal with the bullets above, only smaller modifications should be needed to the text.
ConnectionError should be added; SCTP priority should be removed Fix the inconsistency Add addRemote and removeRemote text related to MPTCP No action Mention Closed Event See item 1, no further action Update UDP-Lite description
Code change:
Each PSK MUST be at least 128-bits long. <del> Each PSK SHOULD be seeded from a source with at least 128-bits of entropy. </del> 5. PSK privacy properties are orthogonal to security properties

Related discussion:
text: Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!
Code change:
attributes to provide better information about the statistical properties of the measurement. <del> A SenML object is referred to as "expanded" if it does not contain any base values and has no relative times. </del> 4.4. <ins> Sometimes it is useful to be able to refer to a defined normalized format for SenML records.  This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. A SenML Record is referred to as "resolved" if it does not contain any base values and has no relative times, but the the base values of the SenML Pack (if any) are applied to the Record.  That is, name and base name are concatenated, base time is added to the time of the Record, if Record did not contain Unit the Base Unit is applied to the record, etc.  In addition the records need to be in chronological order.  An example of this is show in resolved-ex. 4.5. </ins> SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is

Related discussion:
text: Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"
Code change:
Changed the registry policy to: <del> Updated the "Reference" to also refer to this document. </del> <ins> Updated the "Reference" to refer to this document instead of RFC8447. </ins> See expert-pool for additional information about the designated expert pool.

Related discussion:
text: Tweaks to add the D values, explanations about D, etc.
We might want to check that the subsequent registries all have an appropriate value in the column.
Code change:
arbitrary values.  These values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. <del> 10.4. </del> <ins> 9.3. </ins> This document establishes a registry for HTTP datagram context extension type codes.  The "HTTP Context Extension Types" registry

Related discussion:
text: Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.