jiebi/CodeConvo huggingface dataset:
Change:
content type of "application/jose".  The AS MUST extract the payload of the JWS and treat it as the request body for further processing. <ins> This example's JWS header decodes to: And the JWS body decodes to: </ins> If the request being made does not have a message body, such as an HTTP GET, OPTIONS, or DELETE method, the JWS signature is calculated over an empty payload and passed in the "Detached-JWS" header as

Discussion:
(thanks NAME
The example given for "attached JWS" in incorrect: missing JWS headers, incorrect value. Here's a better one for your base64 pleasure: eyJhbGciOiJSUzI1NiIsImtpZCI6IktBZ05wV2JSeXk5TWYycmlrbDQ5OExUaE1ydmtiWldIVlNRT0JDNFZIVTQiLCJodG0iOiJwb3N0IiwiaHR1IjoiL3R4IiwidHMiOjE2MDM4MDA3ODN9.eyJjYXBhYmlsaXRpZXMiOltdLCJjbGllbnQiOnsia2V5Ijp7Imp3ayI6eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsImtpZCI6IktBZ05wV2JSeXk5TWYycmlrbDQ5OExUaE1ydmtiWldIVlNRT0JDNFZIVTQiLCJuIjoibGxXbUhGOFhBMktOTGRteE9QM2t4RDlPWTc2cDBTcjM3amZoejk0YTkzeG0yRk5xb1NQY1JaQVBkMGxxRFM4TjNVaWE1M2RCMjNaNTlPd1k0YnBNX1ZmOEdKdnZwdExXbnhvMVB5aG1Qci1lY2RTQ1JRZFRjX1pjTUY0aFJWNDhxcWx2dUQwbXF0Y0RiSWtTQkR2

Wxob3N0L2NsaWVudC9yZXF1ZXN0LWRvbmUifSwicmVkaXJlY3QiOnRydWV9LCJyZXNvdXJjZXMiOnsiYWN0aW9ucyI6WyJyZWFkIiwicHJpbnQiXSwibG9jYXRpb25zIjpbImh0dHA6Ly9sb2NhbGhvc3QvcGhvdG9zIl0sInR5cGUiOiJwaG90by1hcGkifSwic3ViamVjdCI6eyJzdWJfaWRzIjpbImlzcy1zdWIiLCJlbWFpbCJdfX0.LUyZ8fERmxbYARq8kBYMwzcd8GnCAKAlo2ZSYLRRNAYWPrp2XGLJOvg97WK1idfLB08OJmLVsCXxCvn9mgaAkYNLZjHcusBvY1mNo0E1sdTEr31CVKfC-6WrZCscb8YqE4Ayhh0Te8kzSng3OkLdy7xN4xeKuHzpF7yGsM52JZ0cBcTo6WrYEfGdr08AWQJ59ht72n3jTsmYNy9A6I4Wrvfgj3TNxmwYojpBAicfjnzA1UVcNm9FxiSz1y2tdH7j5rVqBMQife-k9Ewk95vr3lurthenliYSNiUinVfoW1ybnaIBcTtP1YCxg_h1y-B5uZEvYNGCuoCqa6IQ
At this stage,

most of the examples need to be reworked and/or re-generated, especially including things with signatures. They were all originally pulled from a running system based on an older version of the I-D, and so edits to them have been by hand so far. This is a helpful start, so thanks!
Change:
having the resource check that requests have the same string in their "url" fields. <del> 6.4.1. </del> <ins> 6.3.1. </ins> The "url" header parameter specifies the URL RFC3986 to which this JWS object is directed.  The "url" parameter MUST be carried in the protected header of the JWS.  The value of the "url" header MUST be a string representing the URL. <del> 6.5. </del> <ins> 6.4. </ins> In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism.  This mechanism

Discussion:
Instead of defining a whole new key equivalence method just check the JWK verifies the inner JWS.
Change:
always has a zero-length hash for this value. For nodes where an updated path secret was computed in step 1, <del> compute the corresponding node secret and node key pair and replace the values stored at the node with the computed values. </del> <ins> compute the corresponding node key pair and replace the values stored at the node with the computed values. </ins> For example, in order to communicate the example update described in the previous section, the sender would transmit the following values:

Discussion:
This deals cleanly with groups where the private key size doesn't align neatly with a hash function output size (e.g., X448), and saves a few hash invocations by removing intermediate values. A few editorial changes are included here as well. Depends on .
As discussed on call, folks are comfortable with this. Ready to merge, pending
Please merge when get a chance.
Change:
The POST messages MAY be "pipelined" (not illustrated in the diagram above), whereby multiple notifications are sent without waiting for <del> the HTTP response for a previous request. </del> <ins> the HTTP response for a previous POST. </ins> 3.

Discussion:
Getting the draft ready for publication. Did file a bug with libyang folks and even though it was an operator error on my part, the default in yanglint now is to enable all features when none are mentioned. The examples now validate correctly.
Change:
the public key used to sign the JWT doesn't match the one that was included in the creation of the push message. <del> A push subscription that is not restricted to a particular key MAY still validate a token that is present, except for the last check.  A push service MAY then reject a request if the token is found to be invalid. </del> In theory, since the push service was given a public key, the push message request could omit the public key.  On balance, requiring the key keeps things simple and it allows push services to

Discussion:
This was either in error, or could refer to "JWT" instead.
There are multiple references to a token that are unclear: ...
The first is just a mistake; a relic of a previous version. It can be removed. The second refers to JWT. I'll fix that.
Change:
provided by CoAP over UDP.  The Type (T) and Message ID fields in the CoAP message header are elided. <del> The Version (Vers) field is elided as well.  In constrast to the UDP message layer for UDP and DTLS, the CoAP over TCP message layer does not send a version number in each message.  If required in the future, a new Capability and Settings Option (see negotiation) could be defined to support version negotiation. </del> <ins> The Version (Vers) field is elided as well.  In contrast to the message format of CoAP over UDP, the message format for CoAP over TCP does not include a version number.  CoAP is defined in RFC7252 with a version number of 1.  At this time, there is no known reason to support version numbers different from 1.  If version negotiation needs to be addressed in the future, then Capabilities and Settings Messages (CSM see csm) have been specifically designed to enable such a potential feature. </ins> In a stream oriented transport protocol such as TCP, a form of message delimitation is needed.  For this purpose, CoAP over TCP

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
Change:
used in this document, it is always in reference to an RFC1919 proxy server. <del> Of these three concerns, #1 is the most significant, because for some users, the purpose of using a VPN is for anonymity.  However, different VPN users will have different needs, and some VPN users (e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. #2 is a less significant but nonetheless valid concern.  The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 RFC6146.  While disclosure of the RFC4941 IPv6 addresses recommended by I-D.ietf-rtcweb- transports is fairly benign due to their intentionally short </del> <ins> Of these three concerns, the first is the most significant, because for some users, the purpose of using a VPN is for anonymity. However, different VPN users will have different needs, and some VPN users (e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. The second concern is less significant but valid nonetheless.  The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 RFC6146.  While disclosure of the RFC4941 IPv6 addresses recommended by I-D.ietf- rtcweb-transports is fairly benign due to their intentionally short </ins> lifetimes, IPv4 addresses present some challenges.  Although private IPv4 addresses often contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits

Discussion:
This reverts commit 0dac1b124828835c5785c4ae703c26ad3d19f65f.
Change:
support, it MUST NOT parse or respond to the challenge.  If the TokenChallenge contains a non-empty origin_info field, the client MUST validate that the name of the origin that issued the <del> authentication challenge is included in the list of origin names. Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid.  For example, clients can choose to reject challenges that list origin </del> <ins> authentication challenge is included in the list of origin names; if validation fails, the client MUST NOT process or respond to the challenge.  Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid. For example, clients can choose to ignore challenges that list origin </ins> names for which current connection is not authoritative (according to the TLS certificate).

Discussion:
For example, What happens if validation fails here, is the challenge simply ignored or should the client do something more drastic?
Change:
includes it in the new list.) Note that once the GroupContext is updated, its inclusion in the <del> confirmation_tag by way of the key schedule will confirm that all </del> <ins> "confirmation_tag" by way of the key schedule will confirm that all </ins> members of the group agree on the extensions in use. 12.1.8. <del> Add and Remove proposals can be constructed and sent to the group by a party that is outside the group in two cases.  One case, indicated by an "external" SenderType is useful in cases where, for example, an automated service might propose to remove a member of a group who has been inactive for a long time, or propose adding a newly-hired staff member to a group representing a real-world team. ReInit proposals can also be sent to the group by an "external" sender, for example to enforce a changed policy regarding MLS version or ciphersuite. </del> <ins> Proposals can be constructed and sent to the group by a party that is outside the group in two cases.  One case, indicated by an "external" SenderType is useful in cases where, for example, an automated service might propose to remove a member of a group who has been inactive for a long time, or propose adding a newly-hired staff member to a group representing a real-world team.  An "external" sender might send a ReInit proposal, to enforce a changed policy regarding MLS version or ciphersuite. </ins> The "external" SenderType requires that signers are pre-provisioned to the clients within a group and can only be used if the

Discussion:
NAME and I have completed interop testing that covers all of the functionality in the spec. We found a couple of places where there were ambiguities in the spec that led to different implementation decisions, and in the process of resolving those, found a couple of errors / omissions in drarft-19. The current PSK proposal validation forbids with other than . The branch and reinit sections call for the creation of PSK proposals with types and . Given the text in the PSK section, these proposals would be invalid. This PR explicitly allows and in the specific context of those operations. (This is a little pro-forma, since the PSK proposals are only seen by the committer. But it seems good to allow the committer to have consistent PSK proposal validation logic.) The text says that Add, Remove, and ReInit proposals can be sent by external senders, but is silent about other proposal types. This PR explicitly indicates which proposal types may be originated by external senders, and adds an IANA registry column to track. GREASE values for proposal types, credential types, and extension types are defined for use in Capabilities, but nothing currently forbids their use elsewhere. This PR forbids their use in actual Proposal or Credential objects, and in GroupContext extensions. The field of the Proposal object was inconsistently referred to as both and . This PR changes it to be everywhere.
Merge when ready.
Change:
Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent.  In the case of a new remote candidate, <del> connectivity checks will be sent to the new candidate. </del> <ins> connectivity checks will be sent to the new candidate, assuming setLocalDescription has already been called to initialize the ICE gathering process. </ins> 4.1.20.

Discussion:
is supplied to the ICE agent. In the case of a new remote candidate, connectivity checks will be sent to the new candidate. However, if you do this prior to setLD() this will not cause connectivity checks to be sent, right?
That is correct.
Do you think we should change the text to say that? Perhaps "In the case of a new remote candidate, connectivity checks will be sent to the new candidate as soon as setLD(answer) is called, or immediately if it has been called already."
Something like that seems like a good idea. It won't always be setLD with an answer though.
maybe just add ", assuming setLocalDescription has already been called to initialize the ICE gathering process."
Change:
4. A server uses the RateLimit header fields to communicate its quota <del> policies.  Sending the RateLimit-Limit and RateLimit-Reset header fields is REQUIRED; sending RateLimit-Remaining header field is RECOMMENDED. </del> <ins> policies.  A response that includes the RateLimit-Limit header field MUST also include the RateLimit-Reset.  It MAY also include a RateLimit-Remaining header field. </ins> A server MAY return RateLimit header fields independently of the response status code.  This includes on throttled responses.  This

Discussion:
NAME suggestion on server behavior. Thx! -
In section 4 it says, In section 4.1 it says, These statements seem contradictory. I do not see how we can declare as REQUIRED considering many APIs do not and will not implement these headers. It seems to me that if a client receives a header they can choose to either count the requests they make within the time window or they can monitor the . With neither of those values it would be difficult to do something useful. How would you feel about words like this:
NAME we are open to clarifications. The rationale for the current behavior is in URL I think RateLimit-Reset is always REQUIRED.
NAME In theory someone could use RateLimit-Limit to provide a limited number of "free" requests as a trial for their API. They may not choose to have a reset window and just require payment before allocating more calls. This is a bit of an edge case use of the headers, but might be just enough of a justification to limit constraints that we add. Having said this, I still don't understand how we can make any of these headers required considering there are so many existing APIs that don't return these headers today. How does a developer decide if they MUST return these headers for their API? Assuming the "free trial" scenario is not considered a valid scenario for this header, then how would you feel about these words?
SGTM.
Change:
a "decode_error" alert if it is invalid.  It otherwise ignores the extension and MUST NOT use the retry keys. <del> [[OPEN ISSUE: if the client sends a GREASE "encrypted_client_hello" extension, should it also send a GREASE "pre_shared_key" extension? If not, GREASE+ticket is a trivial distinguisher.  See issue #384.]] </del> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in client-behavior.  In particular, the client MAY offer to resume sessions established

Discussion:
Just some minor nits I picked up during a slow pass of the spec.
LGTM pending one nit.
Change:
encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC. <del> The table below summarizes the new key exchange algorithms, which mimic DHE_DSS, DHE_RSA, and DH_anon, respectively. The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy.  With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve p references (see tlsext).  However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy. </del> <ins> tbl2 summarizes the new key exchange algorithms.  All of these key exchange algorithms provide forward secrecy. These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, respectively. With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve preferences (see tlsext).  However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy. </ins> The anonymous key exchange algorithm does not provide authentication of the server or the client.  Like other anonymous TLS key exchanges,

Discussion:
I've restructured a little in support of this. I think that forward secrecy is more pertinent than the analogous finite-field stuff. I can make this less intrusive if you feel like the changes are gratuitous.
Change:
out-of-band knowledge of the application.  However, this context may not always be easily available to entities processing the SenML pack. To facilitate automatic interpretation it is useful to be able to <del> indicate an Internet media type and content-coding right in the SenML Record.  The CoAP Content-Format (RFC7252) provides this information in the form of a single unsigned integer; enclosing a Content-Format number (in this case number 60 as defined for content-type application/cbor in RFC8949) in the Record is illustrated in ex-2. All registered CoAP Content-Format numbers are listed in the IANA.core-parameters IANA.core-parameters as specified by RFC7252. </del> <ins> indicate an Internet media type and, optionally, content codings right in the SenML Record. The CoAP Content-Format (RFC7252) provides this information in the form of a single unsigned integer; enclosing a Content-Format number (in this case number 60 as defined for content-type application/cbor in RFC8949) in the Record is illustrated in ex-2.  All registered CoAP Content-Format numbers are listed in the IANA.core-parameters IANA.core-parameters as specified by RFC7252.  Note that, at the time of writing, the structure of this registry only provides for zero or one content codings; nothing in the present document needs to change if the registry is extended to allow sequences of content codings. </ins> In this example SenML Record, the data value contains a string "foo" and a number 42 encoded in a CBOR RFC8949 array.  Since the example

Discussion:
Address Ben Kaduk's DISCUSS by allowing multiple content codings. Use the opportunity to also address Christer Holmberg's comment that Ben offered some sympathy to -- but staying with the (now lower case) term "content format".
On 2020-08-19, at 04:29, Jim Schaad wrote: (Archived-At: ) Right, this would be what you easily get if you do a “naïve” resolution of “bct" base fields. (However, Section 4 says that you only copy them to records with “vd” fields.) I think that it would be good to do the same thing with “naïve” resolution, i.e., ignore “ct” if there is no “vd”. But I don’t have a strong opinion. Section 3 says: When a SenML Record contains a Data Value field ("vd"), the Record MAY also include a Content-Format indication field. In logic, it simply doesn’t say anything about records without “vd”. In English, it does seem to imply that the MAY does not apply to them. (But then it doesn’t say what is supposed to happen.)
I believe this is now covered by the text in Section 4. For the most part it looks good. However, I am not sure that I understand what the correct behavior for {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","vs":"7.1","ct":"0"} {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1,"ct":"0"} Should the ct be ignored if the value is not "vd"? If it is present but does not make sense what should happen? Jim
Change:
cases.  Also, this document uses terminology defined in I-D.ietf- sacm-terminology. <ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. When the words appear in lower case, their natural language meaning is used. </ins> 2. This document defines requirements based on the SACM use cases

Discussion:
Updates to address 3 of four open issues
Version -09 The document is not consistent if the character following the pithy title is capitalized. A pass needs to be made to fix this.
Hi Jim, I only found 1 straggler in IM-URL there are others please let me know so I can fold it into the -10 draft. Thanks, Nancy
Fixed in Pull request
-version 09 There are two nits that needs to be resolved. Missing 2119 boilerplate Reference to RFC 3444 exists, but is not referred to.
Hi Jim, Will fix in -10 draft..... Thanks, Nancy
Fixed in Pull request
Change:
8. <ins> This section contains considerations for IANA. </ins> 8.1. This document updates the "Well-Known URIs" Registry WellKnownURIs

Discussion:
The caption for is: "'xxx' Well-Known URI", which is probably wrong.
This is a bit of a hard one to decide for me, but I think that you want to define a media type for the JSON directory. I know that in most cases the content will be served from a .well-known location, but that isn't always.
What would be the benefit of a media type here if the content will always be JSON? That is, I don't see how a media type would influence consumers of the resource.
So that you can make it clear that it is this specific JSON, as opposed to some other JSON.
The table appears without the text referring to it, even with an "as follows". It might be better to reference it directly.
Change:
extension, which contains the true extension encrypted under the provider's public key.  The provider can then decrypt the extension and either terminate the connection (in Shared Mode) or forward it to <del> the hidden server (in Split Mode). </del> <ins> the backend server (in Split Mode). </ins> 4.

Discussion:
I decided "hidden" was bad. NAME
+1 to the change. I think that this is the right direction.
Change:
messages for the given endpoint. The key distributor uses the certificate fingerprint of the endpoint <del> along with the value received in the </del> <ins> along with the unique identifier received in the </ins> extension to determine which conference a given DTLS association is associated.

Discussion:
Changes for -07 of the tunnel draft include: Updated references Change status to informational Align terminology with newer UKS draft
LGTM
LGTM