jiebi/CodeConvo huggingface dataset:
Change:
JSONPath allows the wildcard symbol "*" to select any member of an object or any element of an array (wildcard).  The descendant <del> operator ".." selects the node and all its descendants (descendant- selector).  The array slice syntax "[start:end:step]" allows selecting a regular selection of an element from an array, giving a start position, an end position, and possibly a step value that moves the position from the start to the end (slice). </del> <ins> operator ".." selects all the descendants (descendant-selector) of a node.  The array slice syntax "[start:end:step]" allows selecting a regular selection of an element from an array, giving a start position, an end position, and possibly a step value that moves the position from the start to the end (slice). </ins> Filter expressions are supported via the syntax "?(<boolean expr>)" as in

Discussion:
Exclude the node itself Define the term "descendants" more precisely Define the descendant selector semantics more thoroughly Fixes: URL
I would consider adding two additional examples: given: results in: - and results in: - ] ]
I extended the existing example attempting to exhibit the same points as the example above.
Looks good, thanks!
Considering the following input: would evaluate to (in this case the values of the object): I would expect the descendant version: to evaluate to: Yet the example says: Considering the following pseudo logic: In the case of the would be an index wildcard selector. I would expect the descendant selector to (starting by selecting itself) walk through the json structure and select all the results by applying the child selector (dot-member-name, index-selector, index-wild-selector, or wildcard) on each traversed value. Am I misunderstanding something here or is this the intended behavior?
Thanks for raising this. When I was writing the example, I noticed that only a few implementations included the node itself. But the descendant selector semantics currently say: and so I included the "starting" node itself. This is why I included the following text in the commit message: The semantics section needs improving anyway to clarify the semantics of the various forms of the descendants selector. I agree with the semantics proposed above, providing there is a consensus for this in the WG.
In my understanding descendant selector simply extends the single-level operating of child selector , in that it further recursively operates on all other descendant levels. So I agree to Bram's traversal algorithm above. A node is not considered a descendant of itself. Obviously I have not been aware of this behavior.
I haven't checked the examples, but I like the narrative changes.
Change:
Upon joining the system, each client stores its initial cryptographic key material with the Delivery Service.  This key material, called a KeyPackage, advertises the functional abilities of the client such as <del> supported protocol versions, extensions, and the following </del> <ins> supported protocol versions, supported extensions, and the following </ins> cryptographic information: A credential from the Authentication Service attesting to the

Discussion:
Replaces Not compact.
When deploying MLS, the deployer/implementer needs a certain set of choices made. For example, authentication authorities, transport choices, how to interpret application data, etc. This draft could create a succinct summary format that a deployer could use as a checklist to make sure they've done the legwork necessary to be able to deploy MLS safely. this came up in the IETF 113 meeting.
If the draft describes such a summary as a template, then maybe some of the existing deployments could try filling it in, so we could see whether it's sufficient.
I actually think the answer here is fairly compact, and mostly laid out in the arch spec, so it's mainly a question of pulling together the threads. Basically, the application needs to define: An authentication service A delivery service What the content of the messages will be
compact is good and it looks like your list aligns roughly with the intuitions i opened this issue with, so that's good too. Are there any choices about cryptographic primitives that need to be decided as well (e.g. ciphersuite limitations or requirements, expected credential types)? What about MLS extensions or MLS proposals that clients connected to this deployment are expected to support or avoid?
I have no idea whether the template i outlined in is correct, let alone exhuastive. I offer it as a starting point, and won't be upset if anyone wants to step in to improve/correct it.
Really like this direction, few small tweaks.This looks good. Thanks Brendan, Thanks Richard!
Change:
communicate these aspects with each other, including structured access tokens and RS-facing APIs.  This specification also discusses methods for an RS to derive a downstream token for calling another <del> chained RS as well as a client-facing discovery mechanism that can be used to bootstrap the GNAP process when the client instance does not know which AS protects a given RS. </del> <ins> chained RS. </ins> The means of the authorization server issuing the access token to the client instance and the means of the client instance presenting the

Discussion:
See also related PR at ietf-wg-gnap/gnap-core-protocol
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit ec0063ea1a01f824c05137ecaaf8c7760dfee083 https://deploy-preview-26--gnap-resource-servers-editors-URL
Following the review I checked this PR too, seems fine
Change:
Update the "Reference" to also refer to this document. <del> Add the following note: </del> <ins> Add the following notes: </ins> Experts are to verify that there is in fact a publicly available standard. <ins> As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </ins> See expert-pool for additional information about the designated expert pool.

Discussion:
NAME let me know what you think.
I.e., if you actually deploy on the Internet with these experimental code points, and you run into someone using the same code point, you're going to have a bad day. For widespread experiments, we should really be using temporary reservations of some kind instead.
NAME NAME How about we add the following note everywhere we added private use: NOTE: : As specified in {{RFC5226}}, assignments made in the Private Use space "are not generally useful for broad interoperability." It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
LGTM.
Addressed by .
Change:
The format is for DNS over UDP.  Note that this is different than the wire format used in RFC7858.  Also note that while RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later <del> updated by RFC6891, and this protocol does not put any limit on the size of DNS on-the-wire format payloads. </del> <ins> updated by RFC6891, and this protocol allows DNS on-the-wire format payloads of any size. </ins> When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query

Discussion:
Fixes to PR
It doesn't feel to me like "beyond what is already in {{RFC1035}}" really clarifies anything, and might just cause additional confusion, as it makes me as a reader wonder, "oh well what's in 1035? Guess I have to go searching..."
If you want to put the specific limit from RFC 1035 in, that's fine.
Well no, because I don't think there should be a limit. While DNS messages implicitly have a maximum size of 64k in DNS, there's no reason dns-udpwireformat in HTTPS can't surpass that.
NAME It would be an interoperability problem if a DNS API server handed a DNS API client a message that it could not handle. It is reasonable to assume that DNS API clients expect to parse messages as if they were DNS messages.
NAME This was sloppy on my part: I meant the addition to point to RFC 6891; now changed.
Right NAME but my point is that something like multiple AXFR messages re-assembled into one unit is still a DNS message even if it exceeds 64k. From a wire-format point of view, it parses exactly the same way.
NAME Really? Ugh. Gotta love this protocol. So, you would prefer that the text says "URL this protocol allows DNS-on-the-wire format payloads of any size"?
Yes, I would. Realistically almost everything is still going to be sub-10k, but I don't see an intrinsic need to limit it, especially with https channels routinely handling far larger responses.
I think David and I are now in agreement; NAME should consider accepting.
Change:
"encrypted_agg_share" computed above. After receiving the Helper's response, the Leader uses the <del> HpkeCiphertext to finialize a collection job (see collect- </del> <ins> HpkeCiphertext to finalize a collection job (see collect- </ins> finalization). Once an AggregateShareReq has been issued for the batch determined by

Discussion:
DAP-04 will need some routine changes: [x] Update version tags for HPKE to () [x] Bump VDAF-03 to 05 () [x] Update change log () [x] Run spell check ()
Change:
check if this is a more recent frame than any previous ones, as follows: <del> If the enclosing packet number is not greater than the largest one seen so far, the endpoint MUST ignore this frame. </del> If the sequence number in the frame is greater than the largest one seen so far, the endpoint MUST immediately replace old recorded state with values received in this frame.  The endpoint

Discussion:
Changed the error code to FRAMEENCODINGERROR and removed a condition for update which I think may end up causing correctness issues.
I removed the comment you thought was unnecessary, and we can discuss it and any other changes to the section separately.
Change:
set of ICE candidates.  Bundle-only m= sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. <del> For DTLS, all m= sections MUST use the certificate for the identity that has been specified for the PeerConnection; as a result, they MUST all have the same RFC4572 fingerprint value, or this value MUST be a session-level attribute. </del> <ins> For DTLS, all m= sections MUST use all the certificate(s) that have been specified for the PeerConnection; as a result, they MUST all have the same I-D.ietf-mmusic-4572-update fingerprint value(s), or these value(s) MUST be session-level attributes. </ins> Each m= section should be generated as specified in RFC4566, Section 5.14.  For the m= line itself, the following rules MUST be

Discussion:
and
whoops, didn't realize that eric hadn't reviewed before I merged. NAME want to take a quick look?
This updates 4572 so needs to be referenced. Also see URL
This changes the requirements around use of .
Dup of
Minor nits.
Change:
optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined.  As of TLS 1.3, all clients and <del> servers will send at least one extension (at least "key_share" or </del> <ins> servers will send at least one extension (e.g. "key_share" or </ins> "pre_shared_key"). In previous versions of TLS, this field was used for version

Discussion:
The current text works, but tweaking it to be more general for issue is simple.
In the Client Hello (4.1.2) it says: As of TLS 1.3, all clients and servers will send at least one extension (at least "keyshare" or "presharedkey"). I believe that at least the supportedversions extension is also required for a client.
Rather than enumerating everything here, I've pushed a PR to just change "at least" to "e.g.".
I changed this separately.
Change:
"HpkeConfig" is the key config of the aggregator receiving the input share. <del> "enc" is the encapsulated HPKE context, used by the aggregator to </del> <ins> "enc" is the HPKE encapsulated key, used by the aggregator to </ins> decrypt its input share. "payload" is the encrypted input share.

Discussion:
Here are a few small editorial changes: Refer to TLS's "presentation language", per section 3 of the RFC. The output from the HPKE setup function is an encapsulated key, not an encapsulated context. The term context is defined as "A context is an implementation-specific structure...", whereas is alternately described as "an encapsulated KEM shared secret", an "encapsulated key", or a "KEM encapsulated key". Remove stray whitespace from a hyphenated word.
One non-blocking comment.
Change:
Any calls to "Receive" once the Final Message has been delivered will result in errors. <del> 8.2. </del> <ins> 8.3. </ins> The Receive Event is intended to be fired once per application-layer Message sent by the remote endpoint; i.e., it is a desired property

Discussion:
And add an early data metadata value.
I'll dig up relevant discussions from the TLS WG.
See, e.g.: URL
Looks like a good candidate for a read-only recv property…
NAME Aren't all receives read-only?
Looks good - minor nits noted in URL lgtmMuch better I think!
Change:
These examples use HTTP/2 style formatting from RFC7540. These examples use a DNS API service located at <del> https://dnsserver.example.net/dns-query.  The requests are represented as application/dns-udpwirefomat typed bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. </del> <ins> https://dnsserver.example.net/dns-query to resolve the IN A records. </ins> <del> The same DNS query, using the POST method would be: </del> <ins> The requests are represented as application/dns-udpwirefomat typed bodies, but the client indicates it can parse responses in either that format or as a hypothetical JSON-based content type.  The application/simpledns+json type used by this example is currently fictitious. The first example request uses GET to request www.example.com The same DNS query for www.example.com, using the POST method would be: Finally, a GET based query for a.62characterlabel-makes-base64url- distinct-from-standard-base64.example.com is shown as an example to emphasize that the encoding alphabet of base64url is different than regular base64 and that padding is omitted. The DNS query is 94 bytes represented by the following hex encoding </ins> 6.

Discussion:
I've seen an implementation report that confused base64 and base64url; they noted that the examples didn't include one where the distinction was important
NAME yes, there is also the bit about not having the sign paddings that caught me at first. During the DOH proxy implementation, I missed the padding part. I have it implemented in URL and I think it is correct :) Would an example implementation in a language be worth adding to the examples? It may be more straightforward to read than examples. URL documentation says: This may be worth highlighting as what base64url is too.
This is complicated by the fact that some people want the encoding of responses to GET to be media-type-specific.
I think you mean GET request body parameters (not responses - which are always in bodies and not encoded)
Yes, I meant body parameters.
Please stop calling the parameter . It's really confusing. (I just read this and thought to myself "GET doesn't have a body").
note that the current encoded url in the github copy is wrong as it wasn't updated when the dns id changed to 0. I'll fix that as part of making a base 64 example.
Change:
RFC4492, the predecessor of this document has already defined the IANA registries for the following: <del> NamedCurve </del> <ins> Supported Groups </ins> ECPointFormat ECCurveType For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight <del> values (ECPointFormat and ECCurveType) reserved for Private Use.  Any additional assignments require IETF Review. </del> <ins> values (ECPointFormat and ECCurveType) reserved for Private Use.  The policy for any additional assignments is "Specification Required". The previous version of this document required IETF review. </ins> <del> NOTE: IANA, please update the registries to reflect the new policy name. </del> <ins> NOTE: IANA, please update the registries to reflect the new policy. </ins> NOTE: RFC editor please delete these two notes prior to publication.

Discussion:
See Sean Turner's message IETF review is too onerous - use "specification required" instead.
Change:
they can be refreshed.  This applies to both push message subscriptions and receipt subscriptions. <del> A push service might choose to set a fixed expiration time.  If a resource has a known expiration time, expiration information is included in responses to requests that create the resource, or in requests that retrieve a representation of the resource. Expiration is indicated using either the Expires header field, or by setting a "max-age" parameter on a Cache-Control header field (see RFC7234).  The Cache-Control header field MUST also include the "private" directive. </del> A push service can remove a subscription at any time.  If a user agent or application server has an outstanding request to a subscription resource (see monitor), this can be signaled by

Discussion:
Removed references to HTTP cache headers and RFC7234
LGTM
Tracking Darshak Thakore feedback: There was ambiguity about the type of "expiration information" returned: Also I'm assuming here that the "expiration information" refers to the expiration info of the push messages (i.e their TTL), correct? NAME has added a small clarification: URL but an example should be developed.
As discussed on the , the use of HTTP cache headers for graceful subscription expiration was deprecated. Our implementation is currently only reactive when it comes to subscription expiration. That means that we tolerate a break if the server is forced to expire a subscription. Note that the discussion from before was all predicated on a different design, one where individual subscriptions were subjugate to a larger "registration". The current design, even the with the addition of subscription sets, doesn't suffer from the ambiguity problem you described. However, after reviewing the HTTP cache control stuff in more detail, I think that it might be best to remove this feature. The use case (graceful replacement of a subscription), might be important, but I don't think that using response freshness as a proxy for subscription lifetime is correct. If we discover that there is a need, I think that an alternative mechanism will be required. A more direct signal an explicit "refresh now" message - might be a superior option. The consequence of that is that we will rely on the 4xx responses to inform user agents of when the push service has expired a subscription. For the moment, that's probably OK. The consequential drop in reliability should be low.
Change:
The AEAD output consists of the ciphertext output by the AEAD encryption operation.  The length of the plaintext is greater than <del> TLSPlaintext.length due to the inclusion of TLSPlaintext.type and however much padding is supplied by the sender.  The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </del> <ins> TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any padding supplied by the sender.  The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.  Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, </ins> In order to decrypt and verify, the cipher takes as input the key, nonce, and the AEADEncrypted value.  The output is either the

Discussion:
TLSCiphertext.fragment is undefined. I guess it should be "TLSCiphertext.encrypted_record"? This sentence "due to the inclusion of URL and however much padding is supplied by the sender" is unclear to me. Does it mean "due to the inclusion of URL and the padding"?
Change:
described below. When CIDs are being used, the content to be sent is first wrapped <del> along with the true content type and padding into a DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext value is then encrypted. dtls-record12 illustrates the record format. </del> <ins> along with its content type and optional padding into a DTLSInnerPlaintext: </ins> <del> This field contains the byte encoding of a handshake, an alert message, or the raw bytes of the application's data to send. </del> <ins> A copy of DTLSPlaintext.fragment </ins> <del> The DTLSInnerPlaintext.type value contains the content type of the record.  This is the non-obfuscated (true) content type. </del> <ins> A copy of DTLSPlaintext.type </ins> An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for

Discussion:
As discussed with Hannes, this PR replaces
We currently only describe CID processing with AEAD ciphersuites, which seems to imply that the CID extension effectively influences ciphersuite negotiation. The draft should explain how the two - ciphersuite negotiation and CID ext - interact.
I'm not sure, what the scope of this explanation should be? For the MAC, it seems to be obvious, that the block cipher (URL ) extend the data for the MAC accordingly. URL will get That was already discussed in URL So, I'm not sure, if you are the intended "Thomas", which may write that :-)
The question is whether we should define the CID-enhanced MAC calculation for non-AEAD ciphers. The current draft only supports AEAD ciphers. If that's OK then we could just tell implementers that the ciphersuite selection should be influenced by this. Alternatively, we could define the MAC calculation also for non-AEAD ciphers. What would you prefer, Achim?
The latter, I think...
Though Leshan (LWM2M, also supporting CBC) is one of the major using and contributing projects, I would also prefer to have the MAC defined for the none-AEAD.
Here is the PR: URL
Change:
6. <ins> An example of negotiating a WebTransport Stream on an HTTP/2 connection follows.  This example is intended to closely follow the example in Section 5.1 of RFC8441 to help illustrate the differences defined in this document. An example of the server initiating a WebTransport Stream follows. The only difference here is the endpoint that sends the first WT_STREAM frame. 7. </ins> An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. <del> 7. </del> <ins> 8. </ins> The WebTransport framework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence

Discussion:
There is not "right" place to put these, but as they are fairly large (and not that useful, frankly), I am going to suggest that they go after the frame definitions.
Yeah, these used to describe how you'd handle a bunch of new concepts, this is now pretty basic and not particularly enlightening. Mayyyybe useful for the establishment, if you've never seen Extended CONNECT, but... yeah. Seems good to move around now and we can cut it later if we don't end up adding anything useful to them. (I also updated with the section reference change from the other PRs to fix up conflicts, since this moved one of those)
I think these have evolved through various versions of the drafts. When the original draft was presented, things like a "CONNECT stream" and how other streams relate to it were not common knowledge, so the examples were maybe more useful. If everyone has got the idea, we can drop it.