jiebi/CodeConvo huggingface dataset:
Change:
<del> The AS resource (in OAuth 2.0 called "endpoint") /token is the resource targeted by a Client requesting an access token for use when accessing a resource on the RS.  The client makes a POST request to /token on the AS and receives the access token in the POST response. </del> <ins> The AS hosts the /token endpoint that allows a client to request access tokens.  The client makes a POST request to the /token endpoint on the AS and receives the access token in the response (if the request was successful). </ins> <del> The AS resource /introspect is the resource targeted by an RS when requesting additional information regarding a received access </del> <ins> The token introspection endpoint, /introspect, is used by the RS when requesting additional information regarding a received access </ins> token.  The RS makes a POST request to /introspect on the AS and <del> receives such information in the POST response.  (See "Introspection" below.) </del> <ins> receives information about the access token contain in the response.  (See "Introspection" below.) </ins> <del> Access tokens are credentials used to access protected resources. An access token is a data structure representing authorization permissions issued to the client.  Access tokens are generated by the authorization server and consumed by the resource server.  The access token is opaque to the client. </del> <ins> Access tokens are credentials needed to access protected resources.  An access token is a data structure representing authorization permissions issued by the AS to the client.  Access tokens are generated by the authorization server and consumed by the resource server.  The access token content is opaque to the client. </ins> Access tokens can have different formats, and various methods of utilization (e.g., cryptographic properties) based on the security

Discussion:
I went through the overview section and updated the text. The text is already good and only a few minor changes had to be made. I believe we may need to determine (some time in the future) whether it is worthwhile to combine the introduction with the text in the overview section since there is some overlap.
I spotted a few sentences that were missing a word to make sense. I'll go through and try to fix this on Monday, unless someone else manages before me. Otherwise the changes look fine.
Change:
support CONNECT SHOULD restrict its use to a set of known ports or a list of safe request targets; see HTTP for more details. <del> 4.3. </del> <ins> 4.5. </ins> HTTP/3 does not support the HTTP Upgrade mechanism (HTTP) or the 101 (Switching Protocols) informational status code (HTTP). <del> 4.4. </del> <ins> 4.6. </ins> Server push is an interaction mode that permits a server to push a request-response exchange to a client in anticipation of the client

Discussion:
The diff looks larger than it is; I moved some sections around to more closely resemble the TOC of the HTTP/2 spec, and changed a section title that seemed a bit odd a year later. The relocated sections haven't changed. Old TOC: HTTP Request Lifecycle HTTP Message Exchanges Field Formatting and Compression Request Cancellation and Rejection Malformed Requests and Responses The CONNECT Method HTTP Upgrade Server Push New TOC: Expressing HTTP Semantics in HTTP/3 HTTP Message Framing Request Cancellation and Rejection Malformed Requests and Responses HTTP Fields HTTP Control Data Request Pseudo-Header Fields Response Pseudo-Header Fields The CONNECT Method HTTP Upgrade Server Push Comparison H2 TOC: Expressing HTTP Semantics in HTTP/2 HTTP Message Framing Malformed Messages HTTP Fields Field Validity Connection-Specific Header Fields Compressing the Cookie Header Field HTTP Control Data Request Pseudo-Header Fields Response Pseudo-Header Fields Server Push Push Requests Push Responses The CONNECT Method The Upgrade Header Field URL then some further sections as well.
Http-core introduces a new term, "control data," and HTTP/2 has been updated to use this term. HTTP/3 has not. While it was not raised in Auth48, it might be appropriate to align this terminology before we publish these documents together.
This seems like a good change for consistency, even if it might cause the document editor some short term pain.
Closed in .
Change:
server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment. <del> Many HTTPS implementations perform real time third party checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this can happen.  DNS API servers SHOULD utilize OCSP Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party. </del> <ins> Some HTTPS client implementations perform real time third party checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this deadlock can happen.  To avoid the possibility of deadlock, DNS API servers SHOULD bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using RFC6961 for TLS version 1.2. </ins> A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI.

Discussion:
hmm. we do need to fix this - but the proposed fix removes a normative should and introduces tls 1.3 which creates a publishing dependency. The dep is rather minor, but the benefit to DoH even more minor. let me see if I can come up with a fix that is just a SHOULD inline/staple
We cannot say SHOULD use 6961 because that is not allowed in TLS 1.3. I purposely didn't make a publishing dependency to TLS 1.3 by naming it but not giving a link; every reader of this document will know what we are talking about.
I understand the problem. We can probably say something like SHOULD generically staple or inline (such as 6961 where it applies). tls 1.3 does do stapling, it just doesn't do it via 6961.
wdyt of that NAME ?
Reworded again, and back to you NAME
"DNS API servers SHOULD utilize OCSP Stapling [RFC6961] to provide the client with certificate revocation information that does not require contacting a third party." TLS 1.3 will probably be published before DOH and TLS 1.3 deprecates/obsoletes RFC 6961. TLS 1.3 uses only RFC 6066. Maybe you should refer to both RFC 6066 and RFC 6961.
Good catch! Open as PR .
Change:
value is anonymous, JSONPath uses the abstract name "$" to refer to the root node of the argument. <del> JSONPath expressions can use the _dot-notation_ </del> <ins> JSONPath expressions can use the _dot notation_ </ins> <del> or the _bracket-notation_ </del> <ins> or the _bracket notation_ </ins> for paths input to a JSONPath processor.  [1] Where a JSONPath processor uses JSONPath expressions as output paths, these will always be converted to Output Paths which employ the more general <del> _bracket-notation_.  [2] Bracket notation is more general than dot </del> <ins> _bracket notation_.  [2] Bracket notation is more general than dot </ins> notation and can serve as a canonical form when a JSONPath processor uses JSONPath expressions as output paths.

Discussion:
This is a full rebase of branch pr-98 () on current main.
Does this incorporate any changes from the discussions from , or is it a simple rebase?
It is a simple rebase, followed by a number of edits coming from the discussions here. Most of the remaining conversations need some further discussion, so I hope to cover them with my updated slides in a couple of hours.
Looks like a good next step on our path.
Change:
needed to know the minimum safe Finished size.  See RFC8446, Section E.1 for more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ <del> TugB5ddJu3nYg7chcyeIyUqWSbA. </del> <ins> TugB5ddJu3nYg7chcyeIyUqWSbA.  The minimum safe size may vary depending on whether the template was learned via a trusted channel. </ins> In JSON, this length is represented as an integer.

Discussion:
LGTM.
Is it a design goal of this draft to support secure connection, even if the compression template is distributed over an untrusted channel? I believe it is a design goal, and I think it's probably achieved by the current draft (except for questions around the and keys), but it's not stated explicitly in the draft.
Change:
In order to drive the handshake, TLS depends on being able to send and receive handshake messages.  There are two basic functions on this interface: one where QUIC requests handshake messages and one <del> where QUIC provides handshake packets. </del> <ins> where QUIC provides bytes that comprise handshake messages. </ins> Before starting the handshake QUIC provides TLS with the transport parameters (see quic_parameters) that it wishes to carry.

Discussion:
This also adds a paragraph about buffering of CRYPTO frames that references the buffering text in the transport doc. Closes no issue, but there have been complaints.
Change:
parameters are defined: This example uses the ECDSA signing algorithm over the P384 curve and <del> the SHA-256 hashing algorithm for the content digest. </del> <ins> the SHA-512 hashing algorithm for the content digest. </ins> When the proof method is specified in string form, the signing algorithm MUST be derived from the key material (such as using the JWS algorithm in a JWK formatted key), and the content digest <del> algorithm MUST be "sha-512". </del> <ins> algorithm MUST be "sha-256". </ins> When using this method, the signer creates an HTTP Message Signature as described in I-D.ietf-httpbis-message-signatures.  The covered

Discussion:
To edit notification comments on pull requests, go to your .
Nothing more than yaron's feedback
From IETF115 comments: Change the default hash for interaction_hash to sha256, and change the MTI profile to use the same.
Please search for some remaining occurrences of "sha-512".
Change:
close either the ingress or egress direction; these actions are fully independent of each other. <del> If a stream that is critical for an application is closed, the application can generate respective error messages on the application layer to inform the other end and/or the higher layer, and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface for exceptional handling of any stream. </del> <ins> QUIC does not provide an interface for exceptional handling of any stream.  If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually reset the QUIC connection. </ins> Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  In general, data that can be

Discussion:
after discussion with NAME we probably do want to keep the information that "all streams are equal" here. Reverse the order of the sentences here to not bury the lede.
I think that the text on can be removed. This was an interesting discussion in HTTP/3, but I'm not sure that the applicability statement needs to concern itself with this detail.
The intention was, given it was an interesting discussion in H3, it might worth mentioning as other application may have the same "problem". I think it doesn't hurt to keep it. Or is there any concern that the term "critical stream" is maybe not well enough defined?
This reads better for sure, aside from an odd bit of phrasing.
Change:
not always be easily available to entities processing the SenML pack. To facilitate automatic interpretation it is useful to be able to indicate an Internet media type and content-coding right in the SenML <del> Record.  The CoAP Content-Format (Section 12.3 in RFC7252) provides just this information; enclosing a Content-Format number (in this case number 60 as defined for content-type application/cbor in RFC7049) in the Record is illustrated in ex-2.  All registered CoAP Content-Formats are listed in the Content-Formats subregistry of the CoRE Parameters registry IANA.core-parameters. In this example SenML Record the data value contains a string "foo" and a number 42 encoded in a CBOR RFC7049 array.  Since the example </del> <ins> Record.  The CoAP Content-Format (RFC7252) provides just this information; 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-Formats are listed in the Content-Formats IANA.core-parameters of the CoRE Parameters registry IANA.core-parameters. 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 </ins> above uses the JSON format of SenML, the data value containing the <del> binary CBOR value is base64-encoded.  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor. </del> <ins> binary CBOR value is base64-encoded (RFC4648).  The data value after base64 decoding is shown with CBOR diagnostic notation in ex-2-cbor. </ins> 2.

Discussion:
Alexey notes (Archived-At: ): Since data-ct needs almost all of the “normative” ABNF in media-content-type-format, I think the right thing to do would be to fully develop media-content-type-format and make it a normative reference. (Note that media-content-type-format probably needs to be run by httpbis and emailcore [?] soon and when it is nearing WGLC, and there may be surprises there.) This course of action would probably delay data-ct a bit; we might counteract the damage by early registration. Since data-ct only needs an “Expert Review” registration, we could decide to do this when we have processed the reviews that are now incoming.
I didn't do thorough review of the ABNF but otherwise looks good to me Hi all, Sorry for the belated review. I think the document is nearly ready for progression. I have a couple of minor related issues: Terminology Readers should also be familiar with the terms and concepts discussed in [RFC8428]. Awareness of terminology issues discussed in [I-D.bormann-core-media-content-type-format] can also be very It is expired and it is currently not a WG document. At minimum it should be revived. (Or see below) helpful. SenML Content-Format ("ct") Field I wish the document has ABNF for the "ct" field. If you want to use ABNF from draft-bormann-core-media-content-type-format-01, it should be Normative reference. If not, I think you should just cut & paste the ABNF into this document. Best Regards, Alexey
Change:
generated value to provide post-compromise security. The generator of the Commit starts by using the HPKE secret key <del> "leaf_hpke_secret_key" associated with the new leaf ClientInitKey (see initialization-keys) to compute "path_secret[0]" and generate a </del> <ins> "leaf_hpke_secret" associated with the new leaf ClientInitKey (see initialization-keys) to compute "path_secret[0]" and generate a </ins> sequence of "path secrets", one for each ancestor of its leaf.  That is, path_secret[0] is used for the node directly above the leaf, path_secret[1] for its parent, and so on.  At each step, the path

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:
issues related to this authorization.  For example, the server may wish to notify the client about server-initiated revocation. <del> A URI referring to a subscriber agreement or terms of service provided by the server (see below).  Including this field indicates the client's agreement with the referenced terms. </del> <ins> Including this field in a new-registration request, with a value of true, indicates the client's agreement with the terms of service.  This field is not updateable by the client. </ins> <del> A URI from which an array of URIs for application objects submitted by this account can be fetched via a GET request. </del> <ins> A URI from which a list of authorizations submitted by this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "applications" field is an array of strings, where each string is the URI of an authorization belonging to this registration.  The server SHOULD include pending applications, and SHOULD NOT include applications that are invalid.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries.  This field is not updateable by the client. </ins> 6.1.2.1.

Discussion:
This mitigates confusion about how clients should respond when terms of service change.
Updated based on review. Took out the echoing of the field on subsequent requests, because it makes things simpler and clearer.
Change:
the sender will not have the keys necessary to construct a PrivateMessage object. <ins> Some types of proposal cannot be sent by an "external" sender.  Among the proposal types defined in this document, only the following types may be sent by an "external" sender: "add" "remove" "psk" "reinit" "group_context_extensions" Messages from "external" senders containing proposal types other than the above MUST be rejected as malformed.  New proposal types defined in the future MUST define whether they may be sent by "external" senders.  A column is defined in the relevant IANA registry (mls- proposal-types) to reflect this property. </ins> 12.1.8.1. The "external_senders" extension is a group context extension that

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:
The architecture uses the following mechanisms: <del> The architecture attempts to provide privacy, authentication, and safety mechanisms to the extent possible. </del> <ins> The architecture attempts to provide confidentiality, authentication, and safety mechanisms to the extent possible. </ins> 1.1.

Discussion:
Happy to elaborate on them if the motivation is not clear from the changes, let me know!
Thanks NAME b1dc7ba4e26ab17ed12d8a5a2408fe8063b1177a accepts the suggestion. 509d855e5ddba7dd1c5db58646c85516d0b40987 corrects the mistake I had made, which your question was about.
Looks great. Thanks for the PR!
Change:
A "dot-wild-selector" acts as a wildcard by selecting the nodes of all member values of an object in its input nodelist as well as all <del> element nodes of an array in its input nodelist.  The behaviour is unpredictable for an object with duplicate names. </del> <ins> element nodes of an array in its input nodelist. </ins> Applying the "dot-wild-selector" to a primitive JSON value (a number, a string, "true", "false", or "null") selects no node.

Discussion:
Centralize the text that explains how non-interoperable JSON may cause unpredictable behavior. This is a little clumsy as the sections to be referenced are currently unnumbered.
Solves a few "behaviours", too :-)
This centralizing approach is a good thing. I suggest to reuse the phrase "duplicate names" for better recognition of the wording in RFC8259, though is more general, as it addresses more than two.
There may be scope for fine-tuning the section cross-referencing, but this can be deferred to purely editorial activity
Change:
provided by deleting message encryption keys once they've been used to encrypt or decrypt a message. <del> Post-compromise security is also provided for new groups by members regularly generating new KeyPackages and uploading them to the Delivery Service, such that compromised key material won't be used when the member is added to a new group. </del> <ins> New groups are also at risk of using previously compromised keys (as with post-compromise security), if a member is added to a new group via an old KeyPackage whose corresponding private key has been compromised.  This risk can be mitigated by having clients regularly generate new KeyPackages and upload them to the Delivery Service. This way, the key material used to add a member to a new group is more likely to be fresh and less likely to be compromised. </ins> 15.4.

Discussion:
Comment by NAME I personally don't like the underscored words in the html rendering of the document It "blank" the new American spelling of "blanc" ? I find "summarizes" a strange word here. It is not the hash contains a summary one can read. [SECG] has no IETF equivalent? Should it? proposaland -> proposal and I would say "after removing member C" (avoid ambiguity about "every third") I read this wrong the first way, the "," vanishes due to the unscores. Maybe: This section defines tree hashes, the next section defines parent hashes. Or alternatively, leave onlthe the first sentence in 8.8, then put the remainder and next section in two subsections (so 8.8.1 and 8.8.2) Maybe: For example, a malicious group member could otherwise send Maybe: to public keys whose private key was previously compromised. This reads a little odd as "new groups" would have no history and thus no previous compromise.
Filed I think it's important to emphasize the terms being defined, and this seems more readable than a definition list. Note that a hash function is often called a "message digest", in the same sense as the "Weekly github digest" that goes to the mailing list. I think referring to SECG is still pretty state-of-the-art. But apparently RFC 8446 moved on from that, so I updated to use that representation.