jiebi/CodeConvo huggingface dataset:
Change:
In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." EMAIL is used there so the pronouns are mixed. Same comment for 9.1 -- I would suggest replacing "your" with "the user's."

Discussion:
Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed.  While the details vary, what these technologies share is that they have a Web-based (i.e., <del> HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could use the example.org identity provider to prove to others that I was </del> <ins> HTTP/HTTPS) identity provider which attests to Alice's identity.  For instance, if Alice has an account at example.org, Alice could use the example.org identity provider to prove to others that Alice is </ins> alice@example.org.  The development of these technologies allows us <del> to separate calling from identity provision: I could call you on </del> <ins> to separate calling from identity provision: Alice could call you on </ins> Poker Galaxy but identify myself as alice@example.org. Whatever the underlying technology, the general principle is that the

service can strip off any such identity assertions, though it cannot forge new ones.  Note that all of the third-party security mechanisms available (whether X.509 certificates or a third-party IdP) rely on <del> the security of the third party--this is of course also true of your connection to the Web site itself.  Users who wish to assure </del> <ins> the security of the third party--this is of course also true of the user's connection to the Web site itself.  Users who wish to assure </ins> themselves of security against a malicious identity provider can only do so by verifying peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band.
Change:
What happens if fingerprints don't change but identity does, and there's no new connection, (e.g., a codec change). This text needs to say you propagate that identity to the existing connections.
The webrtc text forbids changing of identity. You might want to note that, even if this new language is correct in a more general sense.

Discussion:
connections as well as new connections established using one of those fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires that each media section use the same set of fingerprints for every <del> media section. </del> <ins> media section.  If a new identity attribute is received, then the receiver MUST apply that identity to all existing connections. </ins> If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all.  Because a change in
Change:
The key point is that this is a self-consumed token, so you need to separate it from other self-consumed tokens with different semantics or externally consumed tokens, either by format or by using a separate ke. Ben suggests making this point in 7.4.

Discussion:
fig.assert-ex shows an example assertion formatted as JSON.  In this case, the message has presumably been digitally signed/MACed in some way that the IdP can later verify it, but this is an implementation <del> detail and out of scope of this document.  Line breaks are inserted solely for readability. </del> <ins> detail and out of scope of this document. </ins> For use in signaling, the assertion is serialized into JSON, RFC4648, <del> and used as the value of the "identity" attribute. </del> <ins> and used as the value of the "identity" attribute.  IdPs SHOULD ensure that any assertions they generate cannot be interpreted in a different context.  E.g., they should use a distinct format or have separate cryptographic keys for assertion generation and other purposes.  Line breaks are inserted solely for readability. </ins> 7.7.
Change:
We'll leave this for later.
What's generic is the protocol, but if you have a third party IdP, trust has to be configured. Say that and point to 7.1
See also 5.1.3. Forward reference to 7.1

Discussion:
and to Alice's identity.  In this case, Alice has provided an identity assertion and so Bob's browser contacts Alice's identity provider (again, this is done in a generic way so the browser has no <del> specific knowledge of the IdP) to verify the assertion.  This allows the browser to display a trusted element in the browser chrome </del> <ins> specific knowledge of the IdP) to verify the assertion.  It is also possible to have IdPs with which the browser has a specific trustrelationship, as described in sec.trust-relationships.  This allows the browser to display a trusted element in the browser chrome </ins> indicating that a call is coming in from Alice.  If Alice is in Bob's address book, then this interface might also include her real name, a picture, etc.  The calling site will also provide some user interface

When an endpoint receives an offer or answer that contains an 'identity' attribute, the answerer can use the the attribute <del> information to contact the IdP, and verify the identity of the peer. If the identity verification fails, the answerer MUST discard the offer or answer as malformed. </del> <ins> information to contact the IdP and verify the identity of the peer. If the identity requires a third-party IdP as described in sec.trust- relationships then that IdP will need to have been specifically configured.  If the identity verification fails, the answerer MUST discard the offer or answer as malformed. </ins> 5.1.4.
Change:
As discussed, a couple of minor typos and corrections.
The travis failures here aren't Michael's fault.
I've looked up the missing reference dates and added them. Travis seems happier.

Discussion:
The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC" I-D.ietf-rtcweb- <del> overview.  The major use cases for WebTC technology are real-time </del> <ins> overview.  The major use cases for WebRTC technology are real-time </ins> audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems, (e.g., SIP-basedRFC3261 soft phones) WebRTC communications are directly controlled by some

while scripts are allowed to make HTTP requests via the XMLHttpRequest() API those requests are not allowed to be made to any server, but rather solely to the same ORIGIN from whence the script <del> came xref target="RFC6454"/> (although CORS CORS and WebSockets RFC6455 provide a escape hatch from this restriction, as described below.)  This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks on server B via the user's browser, which protects both the user (e.g., from misuse of his credentials) and the server B (e.g., from DoS attack). </del> <ins> came RFC6454 (although CORS CORS and WebSockets RFC6455 provide a escape hatch from this restriction, as described below.)  This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks on server B via the user's browser, which protects both the user (e.g., from misuse of his credentials) and the server B (e.g., from DoS attack). </ins> More generally, SOP forces scripts from each site to run in their own, isolated, sandboxes.  While there are techniques to allow them

cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address.  Implementations <del> wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems such as Tor. </del> <ins> may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems such as Tor. </ins> 4.3.
Change:
Addressing Alissa's comments. I also added to periods that I noticed were missing.
NAME NAME PTAL
Scratch that, I'm reading backwards. The references are fine.

Discussion:
The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com <del> The attacker forges the response apparently http://calling- </del> <ins> The attacker forges the response apparently from http://calling- </ins> service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure.

user is behind a VPN that masks their IP address.  Implementations may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented <del> systems such as Tor. </del> <ins> systems such as Tor.  See I-D.ietf-rtcweb-ip-handling for additional information. </ins> 4.3.

with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a <del> source of call linkage I-D.ietf-rtcweb-ip-handling </del> <ins> source of call linkage I-D.ietf-rtcweb-ip-handling. </ins> 4.4.2.

and WebRTC is no exception.  Specifically, sites can use the presence or absence of specific devices as a browser fingerprint.  In general, the API needs to be balanced between functionality and the <del> incremental fingerprint risk.  See Fingerprinting </del> <ins> incremental fingerprint risk.  See Fingerprinting. </ins> 5.
Change:
I suspect we'll get dinged here for referring to the RTCWEB WG by name. I'm thinking we can just trim it down to be a one sentence blurb (stolen from overview) and then say this is the threat model/analysis.

Discussion:
Abstract <del> The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC".  The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer.  Unlike most conventional real-time systems (e.g., SIP-based soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges.  For instance, a Web browser might expose a JavaScript API which allows a server to place a video call.  Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera.  This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. </del> <ins> WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. </ins> 1.
Change:
I-D nits complained about a couple of outdated and unused references. This fixes them. Note that a few still remain.

Discussion:
risk is created by allowing calls at all from a page fetched over HTTP. <del> Even if calls are only possible from HTTPS sites, if the site embeds active content (e.g., JavaScript) that is fetched over HTTP or from an untrusted site, because that JavaScript is executed in the security context of the page finer-grained.  Thus, it is also </del> <ins> Even if calls are only possible from HTTPS [RFC2818] sites, if the site embeds active content (e.g., JavaScript) that is fetched over HTTP or from an untrusted site, because that JavaScript is executed in the security context of the page finer-grained.  Thus, it is also </ins> dangerous to allow WebRTC functionality from HTTPS origins that embed mixed content.  Note: this issue is not restricted to PAGES which contain mixed content.  If a page from a given origin ever loads

There also needs to be some mechanism for the browser to verify that the target of the traffic continues to wish to receive it.  Because <del> ICE keepalives are indications, they will not work here.  I-D.ietf- rtcweb-stun-consent-freshness describes the mechanism for providing consent freshness. </del> <ins> ICE keepalives are indications, they will not work here.  RFC7675 describes the mechanism for providing consent freshness. </ins> 4.2.2.

for more details.)  This service must be provided for both data and voice/video.  Ideally the same security mechanisms would be used for both types of content.  Technology for providing this service (for <del> instance, SRTP RFC3711, DTLS RFC4347 and DTLS-SRTP RFC5763) is well </del> <ins> instance, SRTP RFC3711, DTLS RFC6347 and DTLS-SRTP RFC5763) is well </ins> understood.  However, we must examine this technology to the WebRTC context, where the threat model is somewhat different.

provides a number of possible persistent identifiers such as DTLS certificates (if they are reused between connections) and RTCP CNAMES (if generated according to RFC6222 rather than the privacy preserving <del> mode of I-D.ietf-avtcore-6222bis).  In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a source of call linkage I-D.ietf-rtcweb-ip-handling </del> <ins> mode of RFC7022).  In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a source of call linkage I-D.ietf-rtcweb-ip-handling </ins> 4.4.2.
Change:
7de7a76 Update the ABNF to refer to httpbis-semantics; include quoted-pair 7775765 Switch from 7230/7231 to httpbis-semantics 0a57952 Address the question Roman Danyliw did not ask :-)

Discussion:
binary CBOR value is base64-encoded (RFC4648).  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor. <ins> 1.1. As with SenML in general, there is no expectation that the creator of a SenML pack knows (or has negotiated with) each consumer of that pack, which may be very remote in space and particularly in time. This means that the SenML creator in general has no way to know whether the consumer knows: each specific media-type-name used each parameter and each parameter value used each content coding in use each Content-Format number in use for a combination of these What SenML, as well as the new fields defined here, guarantees is that a recipient implementation when it needs to be updated to understand these field values and the values controlled by them; registries are used to evolve these name spaces in a controlled way.  SenML packs can be processed by a consumer while not understanding all the information in them, and information can generally be preserved in this processing such that it is useful for further consumers. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Type, each of the content coding values is appended to the Content- Type value (media type and parameters, if any), separated by a "@" sign, in the order of the content codings were applied (the same <del> order as in RFC7231).  For example (using a content coding value of "deflate" as defined in RFC7230): </del> <ins> order as in I-D.ietf-httpbis-semantics).  For example (using a content coding value of "deflate" as defined in I-D.ietf-httpbis- semantics): </ins> If no "@" sign is present after the media type and parameters, then no content coding has been specified, and the "identity" content

This specification provides a formal definition of the syntax of Content-Format-Spec strings using ABNF notation RFC5234, which contains three new rules and a number of rules collected and adapted <del> from various RFCs RFC7231 RFC6838 RFC5234 RFC8866. </del> <ins> from various RFCs I-D.ietf-httpbis-semantics RFC6838 RFC5234 RFC8866. [[replace: RFC editor: Please replace [RFC-httpbis-semantics] by what gets published from ]] </ins> 7.
Change:
Patch records must match only one Target record Invalid records result in error No Pack state is changed if any invalid records Also: Noted Fetch response must contain each target only once Updated author info

Discussion:
resolved time value and name are matched.  Similarly, when unit is given, only the SenML Records with equal resolved unit and name are matched.  If both time and unit are given in the Fetch Record, both <del> MUST to match for the SenML Record to match. </del> <ins> MUST to match for the SenML Record to match.  Each Target Record MUST be included in the response only once, even if multiple Fetch Records match with the same Target Record. </ins> For example, if the IPSO resource "5850" would have multiple sensor readings (SenML Records) with different time values, the following

Records, to add new Records, and to remove existing Records.  The names, times, and units of the Patch Records are given and matched in same way as for the Fetch Records, except each Patch Record MUST <del> match at most one Target Record.  Patch Packs can also include new values and other SenML fields for the Records.  Application of Patch Packs is idempotent; hence PATCH and iPATCH methods for SenML Packs are equivalent. </del> <ins> match at most one Target Record.  A Patch Record matching more than one Target Record is considered invalid.  Patch Packs can also include new values and other SenML fields for the Records. Application of Patch Packs is idempotent; hence PATCH and iPATCH methods for SenML Packs are equivalent. </ins> When the name in a Patch Record matches with the name in an existing Record, the resolved time values and units (if any) are compared.  If the time values and units either do not exist in both Records or are equal, the Target Record is replaced with the contents of the Patch Record.  All Patch Records MUST contain at least a SenML Value or Sum <del> field.  A Patch Pack with invalid Records MUST be rejected. </del> <ins> field. </ins> If a Patch Record contains a name, or combination of a time value, unit, and a name, that do not exist in any existing Record in the

NOT be added but the matched Record (if any) is removed from the Target Pack. <ins> The Patch Records MUST be applied in the same sequence they are in the Patch Pack. Implementations MUST reject and generate an error for Patch Packs with invalid Records.  If a Patch Pack is rejected, the state of the Target Pack is not changed, i.e., either all or none of the Patch Records are applied. </ins> For example, the following document could be given as an (i)PATCH payload to change/set values of two SenML Records for the example in intro:
Change:
“Are show”
Should clarify that null value for deleting records should always be in "v" field regardless of the value type used in the Record.
Also example of deleting would be useful

Discussion:
a name, that do not exist in any existing Record in the Pack, the given Record, with all the fields it contains, is added to the Pack. <del> If a Patch Record has a value field with value null, the matched Record (if any) is removed from the Pack. </del> <ins> If a Patch Record has a value ("v") field with value null, the matched Record (if any) is removed from the Pack. </ins> <del> For example, the following document could be given as (i)PATCH </del> <ins> For example, the following document could be given as an (i)PATCH </ins> payload to change/set values of two SenML Records for the example in intro: If the request is successful, the resulting representation of the example SenML Pack would be as follows: <ins> As another example, the following document could be given as an (i)PATCH payload to remove the two SenML Records: </ins> 4. The security and privacy considerations of SenML apply also with the

IANA is requested to assign CoAP Content-Format IDs for the SenML PATCH and FETCH media types in the "CoAP Content-Formats" sub- <del> registry, within the "CoRE Parameters" registry RFC7252.  All IDs are assigned from the "IETF Review or IESG Approval" range.  The assigned IDs are show in tbl-coap-content-formats. </del> <ins> registry, within the "CoRE Parameters" registry RFC7252.  The assigned IDs are shown in tbl-coap-content-formats. </ins> 5.2.
Change:
EXI is XML so for consistency we should allow anything that is allowed for (character) XML for EXI as well. Make Klaus' point about content negotiation possibly leading to a format where xpointer does not apply and add the Accept workaround.
LGTM

Discussion:
9.2. In addition to the SenML Fragment Identifiers described above, with <del> the XML SenML formats also the syntax defined in XPointerFramework can be used, as recommended by RFC7303. </del> <ins> the XML and EXI SenML formats also the syntax defined in XPointerFramework can be used.  (This is required by RFC7303 for media types using the "+xml" structured syntax suffix.  SenML allows this for the EXI formats as well for consistency.) Note that fragment identifiers are available to the client side only; they are not provided in transfer protocols such as CoAP or HTTP. Thus, they cannot be used by the server in deciding which media type to send.  Where a server has multiple representations available for a resource identified by a URI, it might send a JSON or CBOR representation when the client was directed to use an XML/EXI fragment identifier with this.  Clients can prevent running into this problem by explicitly requesting an XML or EXI media type (e.g., using the CoAP Accept option) when XML/EXI-only fragment identifier syntax is in use in the URI. </ins> 10.
Change:
The RFC editor will add in the missing comma. Maybe use the usual sequence (confidentiality first). But all this is motherhood and apple pie anyway...
LGTM - thanks

Discussion:
using SenML need to look at the overall context of how these formats will be used to decide if the security is adequate.  In particular for sensitive sensor data and actuation use it is important to ensure <del> that proper security mechanisms are used. </del> <ins> that proper security mechanisms are used to provide, e.g., confidentiality, data integrity, and authentication as appropriate for the usage. </ins> The SenML formats defined by this specification do not contain any executable content.  However, future extensions could potentially
Change:
Clarify semantics of base time 0 ("now")
For base time, draft already has If either the Base Time or Time value is missing, the missing attribute is considered to have a value of zero.

Discussion:
value is used to indicate the number of seconds, excluding leap seconds, since the start of the year 1970 in UTC. <ins> If only one of the Base Sum or Sum value is present, the missing attribute is considered to have a value of zero.  The Base Sum and Sum values are added together to get the sum of measurement.  If neither the Base Sum or Sum are present, then the measurement does not have a sum value. </ins> Representing the statistical characteristics of measurements, such as accuracy, can be very complex.  Future specification may add new attributes to provide better information about the statistical