jiebi/CodeConvo huggingface dataset:
Change:
implementation level only -- they do not influence the result of the evaluation.) <del> A function argument is a "filter-query" or a "comparable". According to filter-selector, a "function-expr" is valid as a "filter-query" or a "comparable". </del> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath implementation MUST raise an error (see synsem-overview).  To define

Discussion:
Any parameter type works with
Indeed. We could make the example more general by not talking about the parameter type there.
Or by adding a bit variety. Done.
How does this work with a parameter?
It doesn't. Example needs to be fixed. Thanks.
Ref: URL Currently is not allowed. The argument is that we've not defined as resulting in a instance (an artifact of not extending the type system to the whole expression), but I don't really see a problem with allowing it. It's pretty intuitive. I can see applications where you'd want an argument to a function to be whether a location in a path is a certain value, e.g. . An function could work this way.
If we extend the use of the type system in this way (any would be of type , possibly after implicit conversion from ), we should also roll out the other types across the spec. Then any would have type and any would have type . This fixes a bug in the current spec which I've only just noticed. The and functions are assumed to be able to take Singular Queries, but as the spec is currently written, these would need converting to using the function.
Thanks. Updating jpt to the new semantics and running it over the spec to find inconsistencies was what I wanted to do over the weekend...
I can next work on implementing this issue on Saturday.
PR attempts to implement this issue using a point solution rather than attempting to roll out the type system across the whole spec.
Approving with several suggestions that I believe will complete the remaining editorial work. (I raised some editorial nits unrelated to this PR in issue URL)
Change:
3.3. As noted in IPHandling, privacy may be breached if a web application <del> running in two browser contexts can determine whether it is running </del> <ins> running in two browsing contexts can determine whether it is running </ins> on the same device.  While the approach in this document prevents the application from directly comparing local private IP addresses, a successful local WebRTC connection can also present a threat to user

Discussion:
PR of
Anyone else want to take a look?
(browser) execution context -> browsing context
It was suggested to replace the name by "browsing context " in the PR of the security consideration. Execution or browser execution context is consistently used in the new commits, and I will create a PR for this if we decide to change the name.
Change:
determine whether we need an extension to indicate that cTLS is in use and with which profile. <del> 8. </del> <ins> 7. </ins> This document requests that a code point be allocated from the "TLS ContentType registry.  This value must be in the range 0-31

Discussion:
This update aims to bring the template-based optimization to the center and focuses on the certificiate-based authentication exchange. Included in this version is the idea to omit the random values transmitted by the client and the server by hashes of the ephemeral public keys.
Change:
between the RTX payload type and its associated primary payload type, as described in RFC4588, Section 4.  If any referenced primary payload types are not present, this MUST result in an <del> error. </del> <ins> error.  Note that RTX payload types may refer to primary payload types which are not supported by the local media implementation, in which case, the RTX payload type MUST also be ignored. </ins> For each specified fmtp parameter that is supported by the local implementation, enable them on the associated media

Discussion:
The bullet in the middle of page 66 (starting "For each specified media format...") states that unsupported media formats must be ignored. The following bullet specifies that "rtx" media formats that refer to "primary payload types [that] are not present" MUST result in an error. Read naïvely, implementors may very well discard a payload type for lack of understanding, and then discover an "rtx" for that discarded PT, and generate an error ("it's not present!"). These bullets need additional text regarding how they interact with each other.
LGTM with comment
Change:
This document. <del> 7.6. </del> <ins> 8.6. </ins> This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM.

Discussion:
This change both describes the existing mechanism (SETTINGS). It also adds a header in the unlikely scenario that we would need to change capsule stream format (instead of just defining new capsules).
Change:
importance.  The client MUST make sure that tokens are not used in a way so that responses risk being associated with the wrong request. One easy way to accomplish this is to implement the Token (or part of <del> the Token) as a sequence number for each connection, starting at zero and reset to zero after rekeying, this approach SHOULD be followed. To avoid collisions the sequence number can be encoded with a fixed length or with some length-value encoding. </del> <ins> the Token) as a sequence number starting at zero for each new or rekeyed secure connection, this approach SHOULD be followed. </ins> 6.

Discussion:
"the encoding of the sequence number has to be chosen . . ." Replace "has to" with "MUST"? (I merged now and proposed the commit in the master branch)
I had to resolve a conflict before merging. Hope I did that right.
Change:
capitals, as shown here. In this document, we use the term "proxy" to refer to the HTTP server <del> that opens the UDP socket and responds to the UDP proxying request. If there are HTTP intermediaries (as defined in HTTP) between the client and the proxy, those are referred to as "intermediaries" in this document. </del> <ins> that acts upon the client's UDP proxying request to open a UDP socket to a target server, and generates the response to this request.  If there are HTTP intermediaries (as defined in HTTP) between the client and the proxy, those are referred to as "intermediaries" in this document. </ins> Note that, when the HTTP version in use does not support multiplexing streams (such as HTTP/1.1), any reference to "stream" in this

Discussion:
In the notational conventions Some might argue an HTTP/3 server already opend a UDP socket :-) so you might want to tighten this a bit to say something like In this document, we use the term "proxy" to refer to the HTTP server that acts upon the client request to open a UDP socket to a target server, and generates the response to this request.
Change:
according to this encoding, then the verifier MUST reject the JWS as malformed. <ins> 5.5. Errors can be reported in ACME both at the HTTP layer and within ACME payloads.  ACME servers can return responses with an HTTP error response code (4XX or 5XX).  For example: If the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed). When the server responds with an error status, it SHOULD provide additional information using problem document I-D.ietf-appsawg-http- problem.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): This list is not exhaustive.  The server MAY return errors whose "type" field is set to a URI other than those defined above.  Servers MUST NOT use the ACME URN namespace for errors other than the standard types.  Clients SHOULD display the "detail" field of such errors. Authorization and challenge objects can also contain error information to indicate why the server was unable to validate authorization. </ins> 6. In this section, we describe the certificate management functions

Discussion:
Move description of registration and authorization objects to Certificate Management section Re-frame Protocol Elements section to be more clearly about the transport layer Fix some references
Change:
untrusted party.  Instead, a client MUST only trust DNS API server that is configured as trustworthy. <ins> A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy expected by the user of the client. </ins> 9. Local policy considerations and similar factors mean different DNS

Discussion:
If you're ok with the language I think this is ready to go into the draft based on list discussion. (this does imply to has consensus - everything needs consensus, but as a process matter we need to try and channel those discussions into text for consideration.. its open to feedback, of course)
forked off from which deals with error handling, text on what happens if you choose to handle errors in a non doh fashion related to mailing list thread: A question on the mix of DNS and HTTP semantics
Change:
The Local Endpoint MUST be specified if the Preconnection is used to Listen() for incoming Connections, but is OPTIONAL if it is used to <del> Initiate() connections.  The Remote Endpoint MUST be specified if the </del> <ins> Initiate() connections.  If no Local Endpoint is specified, the Transport System will assign an ephemeral local port to the Connection.  The Remote Endpoint MUST be specified if the </ins> Preconnection is used to Initiate() Connections, but is OPTIONAL if it is used to Listen() for incoming Connections.  The Local Endpoint and the Remote Endpoint MUST both be specified if a peer-to-peer

Discussion:
Done.
Impl draft section 4.6 (Implementing listeners): "If no Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error." Do we need an interface for the application to indicate that an ephemeral port should be used?
It's implicit in the old socket API - accept just gives me a new socket, which I can use to continue communication, but I don't see the port numbers associated with this socket and never have to say that they are ephermal. I believe it's similarly implicit in ours. So ... what's missing?
The text above says "use an ephemeral port or generate an error". So when would you throw an error? If the assumption is that always an ephemeral port should be used (no matter actually how the underlying interfaces works) that should be stated (in the API doc).
If you do not use an "ephemeral port", and choose to specify the port - then you may get the error if it can't be completed.
... or if the system is out of resources for some reasons. Just like "accept" can fail in the normal socket API.
That too.
NAME requested that I adapt the "error" text in the implementation draft too. In doing so, I noticed: I don't understand NAME comment above, about choosing the specify the port. I think this kind of error was possible with sockets somehow, but this text talks about not specifying a Local Endpoint. Technically, I think not specifying a Local Endpoint yet specifying a port is not possible.Regarding my own comment, any call may fail for reasons such as the system being out of resources; I think mentioning this in the text here doesn't add any value though. As a result, I'll remove the part about the error from the text in my update to PR .
This seems like what was agreed.This change is fine. You also need to adapt the implementation doc to remove the "or" part: "either use an ephemeral port or generate an error."
Change:
3. <del> This document has no IANA actions (yet). </del> <ins> A stable identifier for an application server - such as a public key or a token - could also be used to associate a subscription with the application server. Subscription association reduces the reliance on endpoint secrecy by requiring proof of possession to be demonstrated by an application server when requesting delivery of a push message.  This provides an additional level of protection against leaking of the details of the push subscription. 3.1. The user agent includes the public key or token of the application server when requesting the creation of a subscription.  For example, the Web Push API API could allow an application to provide a public key as part of a new field on the "PushSubscriptionOptions" dictionary. This token might then be added to the request to create a push subscription. Allowing the inclusion of multiple keys when creating a subscription would allow a subscription to be associated with multiple application servers or application server instances.  This would require more state to be maintained by the push service for each subscription. 3.2. When a subscription has been associated with an application server, the request for push message delivery MUST include proof of possession for the associated private key or token that was used when creating the subscription.  Requests that do not contain proof of possession are rejected with a 401 (Unauthorized) status code. </ins> 4. <ins> This document has no IANA actions (yet). 5. </ins> TLS 1.2 RFC5246 does not provide any confidentiality protections for client certificates.  A network attacker can therefore see the identification information that is provided by the application

Discussion:
NAME can you check that this is all OK with you? I've made you an author :)
SG, thanks. The only difference with my PR seems to be removal of details, which I guess are too specific for the proposal phase.
Change:
The following sections describes APIs that are considered necessary to implement exported authenticators.  These are informative only. <del> 5.1. </del> <ins> 6.1. </ins> The "request" API takes as input:

Discussion:
URL you don't want to provide one. TLS allows Certificate to be empty, with a missing CertificateVerify and Finished as normal. That would be a nice change. Alternatively, we could insist on the using application managing this, but it seems like an authenticated refusal is nice.
Resolved in PR
Change:
DNS responses sometimes contain optional data in the additional section.  In-domain glue records, however, are not optional.  Several other protocol extensions, when used, are also not optional.  This <del> includes TSIG RFC2845, OPT RFC6891, and SIG(0) RFC2931. </del> <ins> includes TSIG RFC8945, OPT RFC6891, and SIG(0) RFC2931. </ins> At the time of this writing, addresses (A or AAAA records) for a delegation's authoritative name servers are the only type of glue

Discussion:
idnits mentions this: -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945)
Change:
consider the effects of network design decisions on application-level performance, with considerations for the impact on video delivery. <del> Much of the focus of this document is on reliable media using HTTP over TCP, which is widely used because </del> <ins> Much of the focus of this document is on reliable media using HTTP. HTTP is widely used because </ins> support for HTTP is widely available in a wide range of operating systems,

Discussion:
From NAME " reliable media using HTTP over TCP," should MOQ be cited here ? or HTTP/3 over QUIC ?
NAME - Thanks for catching this. The relevant point here is that HTTP is carried over reliable transport protocols. The behavior of specific transport protocols is described in subsections of Section 6. I've clarified that in Section 2.
Change:
1. <del> QUIC QUIC is a new transport protocol currently under development in the IETF quic working group, focusing on support of semantics as needed for HTTP/2 QUIC-HTTP such as stream-multiplexing to avoid head-of-line blocking.  Based on current deployment practices, QUIC is encapsulated in UDP.  The version of QUIC that is currently under development will integrate TLS 1.3 TLS13 to encrypt all payload data and most control information. </del> <ins> QUIC QUIC is a new transport protocol providing a number of advanced features.  While initially designed for the HTTP use case, like most transports it is intended for use with a much wider variety of applications.  QUIC is encapsulated in UDP.  The version of QUIC that is currently under development will integrate TLS 1.3 TLS13 to encrypt all payload data and most control information.  HTTP operating over QUIC is known as HTTP/3. </ins> This document provides guidance for application developers that want to use the QUIC protocol without implementing it on their own.  This <del> includes general guidance for application use of HTTP/2 over QUIC as well as the use of other application layer protocols over QUIC.  For specific guidance on how to integrate HTTP/2 with QUIC, see QUIC- HTTP. </del> <ins> includes general guidance for applications operating over HTTP/3 or directly over QUIC.  For specific guidance on how to integrate HTTP/3 with QUIC, see QUIC-HTTP. </ins> In the following sections we discuss specific caveats to QUIC's applicability, and issues that application developers must consider

Discussion:
Intended to , ,
The draft says section 8 of quic-transport; it's section 13.
It is odd that this section doesn't mention QUIC's robustness to NAT rebinding at all. While this won't work behind 4-tuple load balancers, middlebox timers may be irrelevant depending on the conesequences of the timeout.
While TFO has some 0RTT-like properties, it does not fully replace it, not only because the SYN or option gets scrubbed, but also because you're limited to one packet payload. Also, this ought to mention TLS stacks that offer replay protection. I would think a modern QUIC interface would offer a signal to separate 0RTT from 1RTT data, so that both senders and receivers can manage their application data appropriately.
will be
This is editorial, but the whole introduction is written as if the quic drafts are some early concept kicking around in the working group. This will not age well, and the intro should be worded as if it were already a published RFC. The intro still talks about "HTTP/2 over QUIC" when it's now HTTP/3.
Change:
cloud vendor would be able to reassemble all the input shares and defeat privacy. <ins> 8.6.1. Using a report in multiple batches, or multiple times within a single batch, is considered a privacy violation, since it may leak more information about that report than intended by the PDA protocol.  For example, this may violate differential privacy.  To mitigate this issue, the core specification imposes an ordering on reports so that aggregators can cheaply prevent replays attacks. Aggregate requests are ordered as follows: We say that a report "R2" _follows_ report "R1" if either "R2.time > R1.time" or "R2.time == R1.time" and "R2.jitter > R1.jitter".  If "R2.time < R1.time", or "R2.time == R1.time" but "R2.jitter <= R1.jitter", then we say that "R2" _does not follow_ "R1". To prevent replay attacks, it suffices for each aggregator to ensure that each report it consumes follows the previous one it consumed. To prevent the adversary from tampering with the ordering of reports, honest clients incorporate the ordering-sensitive parameters "(time, jitter)" into the AAD for HPKE encryption. Note that this strategy may result in dropping reports that happen to have the same timestamp and jitter value. </ins> 8.7. 8.7.1.

Discussion:
For privacy reasons, leaders should not be allowed to replay a given report more than once within the context of a single batch. The current verify+collect model runs in a "streaming mode," wherein the leader sends slices of batch shares to helpers for verification and aggregation. If we changed this to require the leader to send all batch shares in a single verify+collect flow, then replay prevention would be simpler: just scan the list and check for dupes. If we stick with the current model, then the helper must necessarily store some state (on the leader, most likely) representing the shares processed. This state could then be consulted when asked to verify+collect any new share. (We can probably spell out a number of ways to do store this state, but ideally it should not be linear in the number of shares collected so far.) We'd likely also need a way for the leader to request that the helper produce the final aggregate output once the batch is "done" being verified and collected.
One downside to this approach is that it requires the leader to queue up the entire batch of reports before sending the first aggregate request to the helper. This may be OK for some deployments, but it might not be workable for all. I think this is worth pursuing. This is already in the protocol. (See "output share request".)
We could require that the leader feed the helper reports with monotonically increasing timestamps, such that the helper can simply maintain a single timestamp and reject any report older than that. However I'm not sure if that's practical given that clients may submit reports out of order.
One intermediate option would be to maintain a jitter buffer on the leader, so that they keep reports for a few minutes and then feed them out in order. You would still lose some reports, but not too many.
I have a few questions but nothing blocking.
Change:
4.1.4. <del> Servers send this message in response to a ClientHello message if they were able to find an acceptable set of algorithms and groups that are mutually supported, but the client's ClientHello did not contain sufficient information to proceed with the handshake.  If a server cannot successfully select algorithms and groups, it MUST abort the handshake with a "handshake_failure" alert. </del> <ins> The server will send this message in response to a ClientHello message if it is able to find an acceptable set of parameters but the ClientHello does not contain sufficient information to proceed with the handshake. </ins> Structure of this message:

Discussion:
This is a giant pile of nitpicks, loosely inspired by the FFDHE alert discussion. The old text specifies a handshakefailure which is redundant with and contradicts the Cryptographic Negotiation section. The old text says only handshakefailure is allowed while Cryptographic Negotiation allows both handshakefailure and insufficientsecurity. Fix this by avoiding redundancy as the failure cases are global to the overall negotiation algorithm. Next, align the tense with itself and the rest of the text. Most of the text appears to be written in present tense. The old text for SH said: The server will send [...] when it was able to [...] which is a little odd. Also align the wording between the two. Talk about a server (singular) to match Cryptographic Negotiation and say "parameters" rather than "algorithms" or "algorithms and groups". Also be consistent about the SH vs. HRR condition. The SH section said "the client’s key_share extension was acceptable" while the HRR section said "the client’s ClientHello did not contain sufficient information to proceed with the handshake". Use the more general one.
Seems reasonable. I a little bit wondered whether to replace "it" with "the server", but the pronoun's meaning should be clear, here.
Seems clear enough to me, but I'm equally happy with the other wording. shrug
This does seem clearer. And shorter!