jiebi/CodeConvo huggingface dataset:
Change:
validates the hash.  If the client instance does not use an interaction finish method or does not check the interaction finish hash value, the compromised AS can be granted a valid access token on <del> behalf of the resource owner.  See attack-surfaces for details of one </del> <ins> behalf of the resource owner.  See AXELAND2021 for details of one </ins> such attack, which has been since addressed in this document by including the grant endpoint in the interaction hash calculation. The client instance still needs to validate the hash for the attack

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 8fe956adfc5cb03ad39042fa3e3497c42d7fbce1 Inspect the deploy log: Browse the preview:
Some unicode characters within the document break the build tools, specifically we see being changed to in the rendered document.
Change:
Connection-oriented transport protocols), or when the first Message has been received from the Remote Endpoint (for Connectionless protocols), causing a new Connection to be created.  The resulting <del> Connection is contained within the ConnectionReceived event, and is </del> <ins> Connection is contained within the ConnectionReceived Event, and is </ins> ready to use as soon as it is passed to the application via the event. <ins> If the caller wants to rate-limit the number of inbound Connections that will be delivered, it can set a cap using SetNewConnectionLimit().  This mechanism allows a server to protect itself from being drained of resources.  Each time a new Connection is delivered by the ConnectionReceived Event, the value is automatically decremented.  Once the value reaches zero, no further Connections will be delivered until the caller sets the limit to a higher value.  By default, this value is Infinite.  The caller is also able to reset the value to Infinite at any point. </ins> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. <del> A Stopped event occurs after the Listener has stopped listening. </del> <ins> A Stopped Event occurs after the Listener has stopped listening. </ins> 6.3.

Discussion:
This implements what we discussed on
There should be a way to put back pressure or limits on the number of inbound connections for a listener. The two approaches are: To have a one-to-one callback for listen -> received connect To have a way to set a numeric limit of new inbound connections My preference is (2). (1) has an issue of being very impractical for servers that don't know how many connections they'll receive, and may require them to call a thousand times without any other activity. (2) is more similar to how calling on sockets work.
+1 on variant 2 - indeed it's common and known to people from sockets, and just seems like the easier and more efficient solution (albeit maybe less "beautiful", in a way).
+1 on variant 2 as well.
Do variant 2.
I believe that PR fully addresses this; hence I'm closing it.
lgtm, thanks!This is surely useful as-is. Considering the recent discussion on the list (dynamic per-IP rejection possibilities), I'm not sure it's rich enough... but it's certainly a good starting point. I'm also not sure how much of what's been discussed really should be a part of the spec.
Change:
endpoint abandons a path, the peer will not receive any more non- probing packets on that path. <del> An endpoint that wants to close a path SHOULD NOT rely on implicit signals like idle time or packet losses, but instead SHOULD use explicit request to terminate path by sending the PATH_ABANDON frame (see path-abandon-frame). </del> <ins> An endpoint that wants to close a path SHOULD use explicit request to terminate the path by sending the PATH_ABANDON frame (see path- abandon-close).  Note that while abandoning a path implies Connection ID retirement, only retiring the associated Connection ID does not necessarily advertise path abandon (see retire-cid-close).  However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see idle-time-close). Note that other explicit closing mechanisms of QUIC-TRANSPORT still apply on the whole connection.  In particular, the reception of either a CONNECTION_CLOSE (Section 10.2 of QUIC-TRANSPORT) or a Stateless Reset (Section 10.3 of QUIC-TRANSPORT) closes the connection. </ins> 4.2.1.

Discussion:
.
Should the spec say something about stateless reset? Suppose a node is sending on two paths with two different DCID and two corresponding stateless reset secrets, and receives a stateless reset packet that matches the reset secret on the first path. Should it: 1) Abandon that path and continue the connection with the other path? 2) Abandon the connection?
That's a good point. RFC9000 states that stateless resets should be used in last resort when the endpoint does not have access to the connection state. If hosts have still access to the connection state and want to abandon a specific path, I would expect them to rely on PATH_ABANDON frame (or on path idle timeout). So when receiving a stateless reset, I would abandon the connection. Depending on the number of impacts on existing RFC9000 mechanisms, it may be useful to write a section (or at least, a paragraph) clarifying these points.
We should review the current text and make sure we cover everything clearly. Maybe add some more text to the intro part of 3.2
Careful with implicit actions!LGTM
Change:
multiplexing or non-multiplexing endpoints. The browser will only gather RTP candidates.  This halves the <del> number of candidates that the offerer needs to gather.  When acting as answerer, the implementation will reject any m= section that does not contain an "a=rtcp-mux" attribute. </del> <ins> number of candidates that the offerer needs to gather.  Applying a description with an m= section that does not contain an "a=rtcp- mux" attribute will cause an error to be returned. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to

Discussion:
This will happen when applying either an offer or an answer, for consistency. Also, any "semantics verification" failure will now result in an error, which was assumed but not explicitly stated. Fixes issue .
This is a good start, but you'll also want to update 4.1.1, 5.3.1 to reflect this (new) policy. Note though that this will end up being inconsistent with the handling of max-bundle as it is described in 4.1.1, although I still think this is the right approach.
Updated 4.1.1. I thought I already made the needed change to 5.3.1, what else needs to be changed?
I may be overlooking something, but I don't think this behavior is documented anywhere. I think the choices, in order of harshness, are: Silently fails, and you don't get RTCP negotiationneeded fires, and the m= section is port-zeroed in the next offer setRemoteDescription throws an error I'd lean towards the middle option, but that assumes that applications listen to negotiationneeded.
I lean toward the last option, as a violation of an invariant set by the offerer.
Agree that this should be documented somewhere.
+1 on the throw an error option
The general policy that we discussed here in Seattle was that any spec violation should lead to a setRD exception, not a zero port. For the rtcp-mux-only doc, we probably should have some language that makes rtcp-mux in the answer a MUST.
Resolved by
Change:
10. <del> Joe Hildebrand contributed lots of material for a different iteration of this document.  Helpful early comments were given by Ben Schwartz and Mark Nottingham. </del> <ins> This work required a high level of cooperation between experts in different technologies.  Thank you Ray Bellis, Stephane Bortzmeyer, Manu Bretelle, Tony Finch, Daniel Kahn Gilmor, Olafur Guomundsson, Wes Hardaker, Rory Hewitt, Joe Hildebrand, David Lawrence, Eliot Lear, John Mattson, Alex Mayrhofer, Mark Nottingham, Jim Reid, Adam Roach, Ben Schwartz, Davey Song, Daniel Stenberg, Andrew Sullivan, Martin Thomson, and Sam Weiler. </ins> 11.  References

Discussion:
recently I've left the ack section mostly untouched until the final (or near final) edit. Easier to deal with it once. However I think its good idea to have leave the PR open and amend it as useful
OK, having a "living" PR seems OK.
Change:
endpoints and a resource lookup MUST return a list of links to resources. <del> RD Lookup does not expose registration resources directly, but returns link content from registration resource entries which satisfy RD Lookup queries. </del> <ins> While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT attempt to dereference or manipulate them. </ins> The lookup type is selected by a URI endpoint, which is indicated by a Resource Type as per lookup-types below: <del> Each endpoint and resource lookup result returns respectively the scheme (IP address and port) followed by the path part of the URI of every endpoint and resource inside angle brackets ("<>") and followed by the other parameters. The target of these links SHOULD be the actual location of the endpoint or resource, but MAY be an intermediate proxy e.g. in the case of an HTTP lookup interface for CoAP endpoints. In case that a group does not implement any multicast address, the group lookup returns every group lookup with a group base resource value encapsulated within angle brackets (e.g. "/rd/look-up"). Otherwise, the group lookup returns the multicast address of the group inside angle brackets. </del> <ins> Resource lookup results in links that are semantically equivalent to the links submitted to the RD if they were accessed on the endpoint itself.  The links and link parameters returned are equal to the submitted ones except for anchor, which gets resolved according to the endpoint's context.  That allows the client to interpret the response as links without any further knowledge of what the RD does. The Resource Directory MAY replace the contexts with a configured intermediate proxy, e.g. in the case of an HTTP lookup interface for CoAP endpoints. Endpoint and group lookups result in links to the selected registration and group resources.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, if present) and context (con).  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </ins> Using the Accept Option, the requester can control whether this list is returned in CoRE Link Format ("application/link-format", default)

Discussion:
This is the documenting text to the changes worked out first on the examples in . It does not (yet) contain explaining overall text, but updates the various smaller mentions of the parameter to fit together. It does change the semantics of using on a registration update, but I believe that the previous wording was not what the original authors had intended. (Previously, an endpoint registering over TCP would need to explicitly repeat its con on every update).
Change:
resolution is 1280x720, and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360.  If downscaling cannot be applied, the encoding MUST NOT be <del> transmitted, and an error SHOULD be surfaced to the application. </del> <ins> transmitted, and an error SHOULD be raised to the application. </ins> If the encoder resolution is less than the minimum size permitted by the attribute, the encoding MUST NOT be transmitted, and an <del> error SHOULD be surfaced to the application; the encoder MUST NOT </del> <ins> error SHOULD be raised to the application; the encoder MUST NOT </ins> apply upscaling.  JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder.

Discussion:
The verb "surfaced" appears three times in the document without support or definition. Can you replace them with simpler language?
I don't see a reason to change this. It seems like relatively straightforward langauge.
I don't care. FWIW ... I asked a few developers what surfaced in an API meant and it did not seem a common term they used but given context they all read it the way we mean in spec..
The first two, which are about errors, will be changed to "raised" The last one, which is about candidates will be changed to "made available"
LGTM
Change:
the certificate to be issued: A CSR encoding the parameters for the certificate being requested <del> RFC2986.  The CSR is sent in the Base64url-encoded version of the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) </del> <ins> RFC2986.  The CSR is sent in the base64url-encoded version of the DER format.  (Note: Because this field uses base64url, and does not include headers, it is different from PEM.) </ins> The requested value of the notBefore field in the certificate, in the date format defined in

Discussion:
Also fix an example date and fix an RFC reference to not be redundant.
Merging based on manual review, since CircleCI for PRs seems to be busted.
Change:
5. <del> TLS session tickets are specific to the QUIC version of the connection that provided them.  Clients MUST NOT use a session ticket from a QUICv1 connection to initiate a QUICv2 connection, or vice versa. Servers SHOULD validate the originating version of any session ticket and not resume from any ticket issued from a different version.  This results in falling back to a full TLS handshake, without 0-RTT. </del> <ins> TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them.  Clients SHOULD NOT use a session ticket or token from a QUICv1 connection to initiate a QUICv2 connection, or vice versa. Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version.  A rejected ticket results in falling back to a full TLS handshake, without 0-RTT.  A rejected token results in the client address remaining unverified, which limits the amount of data the server can send. </ins> After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than original one.

Discussion:
Are NEW_TOKEN tokens reusable across versions? On current patterns, probably not, but we should write it down.
Agreed, we should mirror here what we did for TLS resumption tickets
Change:
replace draft-ietf-acme-acme above with the RFC number assigned to this ]] <del> Applications which use this media type: Any MIME-complaint transport </del> <ins> Applications which use this media type: Any MIME-compliant transport </ins> Additional information:

Discussion:
Thanks to NAME for the report. Resolves URL
s/MIME-complaint/MIME-compliant/
NAME thanks - URL
Change:
security considerations for this document. While formally the JSEP interface is an API, it is better to think of <del> it is an Internet protocol, with the application JavaScript being </del> <ins> it as an Internet protocol, with the application JavaScript being </ins> untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious

Discussion:
I'm sure the RFC editor would have caught this nit: While formally the JSEP interface is an API, it is better to think of it is an Internet protocol s/is an Internet/as an Internet/
Change:
cipher suite, it may be possible to identify that host based on the contents of unencrypted handshake messages. <ins> Beyond these primary security and privacy goals, ECH also aims to hide, to some extent, (a) whether or not a specific server supports ECH and (b) whether or not ECH was accepted for a particular connection.  ECH aims to achieve both properties, assuming the attacker is passive and does not know the set of ECH configurations offered by the client-facing server.  It does not achieve these properties for active attackers.  More specifically: Passive attackers with a known ECH configuration can distinguish between a connection that negotiates ECH with that configuration and one which does not, because the latter used a GREASE "encrypted_client_hello" extension (as specified in grease- extensions) or a different ECH configuration. Passive attackers without the ECH configuration cannot distinguish between a connection that negotiates ECH and one which uses a GREASE "encrypted_client_hello" extension. Active attackers can distinguish between a connection that negotiates ECH and one which uses a GREASE "encrypted_client_hello" extension. See do-not-stick-out for more discussion about the "do not stick out" criteria from RFC8744. </ins> 10.2. In comparison to I-D.kazuho-protected-sni, wherein DNS Resource

Discussion:
cc NAME
In just a few sentences, let's define the anonymity set and say what it means for connections to end points in this set to be indistignuishable. We might also enumerate non-goals (though we still need consensus on what these are).
I've not yet gotten around to the PR yet, but here's the gist: Attackers: Passive attackers are those which cannot probe, e.g., buggy middleboxes that filter based on plaintext packet contents. Active attackers can probe, e.g., censors. Goals: ECH does not negatively affect any existing security properties of TLS 1.3. ECH connections to servers in the same anonymity set are indistinguishable from one another for passive and active attackers, modulo traffic analysis. (Note: an anonymity set is determined by the client and server parameters, e.g., the SNI, supported application protocols, and so on.) ECH support is secret from passive attackers who don't know the ECH configuration, but not active attackers. ECH usage is secret from passive attackers who don't know the ECH configuration, but not active attackers. More specifically: Passive attackers with a known ECH configuration can distinguish between a connection that negotiates ECH with that configuration and one which does not (GREASEd or using a different configuration). Passive attackers without the ECH configuration cannot distinguish between a connection that negotiates ECH and one which does not (but GREASEd). Active attackers can distinguish between a connection that negotiates ECH and one which does not (but GREASEd).
Yeah this looks good.
From the interim: merge this as a PR and then address censorship separately (if desired).
Change:
attribute of the SDP RFC8122. This object is encoded in a RFC8259 string for passing to the IdP. <ins> The identity assertion returned by the IdP, which is encoded in the "identity" attribute, is a JSON object that is encoded as described in sec.carry-assertion. </ins> This structure does not need to be interpreted by the IdP or the IdP proxy.  It is consumed solely by the RP's browser.  The IdP merely

Discussion:
The description of how an assertion is constructed seemed to imply that the object with the fingerprints was what went in a=identity. You had to read much further down to learn that this wasn't right and that it was really the assertion. This just moves some of the critical text up, duplicating it really, so that this confusion is less likely.
Change:
4. SFrame must be integrated with an E2EE key management framework to <del> exchange and rotate the encryption keys such as MLSPROTO which scales to very large groups.  Call members will create a MLS group to exchange the encryption keys for all further calls for that group. When a client joins the call, they create a random key material and encrypt it to every other client on the call using their MLS application secret.  This key material is passed to SFrame to derive SFrame keys for that client.  When group membership changes, the active clients in the call must update their keys for "Forward Secrecy" and "Post Compromise Security".  Key ratcheting can be used when a new member joins the group but for member leave events, a fresh key material will be generated by each client endpoint in the call and encrypt it using their MLS application secret. If authentication is enabled, every client will also generate public- private key pair for signing and exchange the public part with the secret key material. </del> <ins> exchange and rotate the encryption keys.  This framework will maintain a group of participant endpoints who are in the call.  At call setup time, each endpoint will create a fresh key material and optionally signing key pair for that call and encrypt them to every other endpoints.  They encrypted keys are delivered by the messaging delivery server using a reliable channel. The key management framework will monitor the group changes, and exchange new keys when necessary.  It is up to the application to define this group, for example one application could have ephemeral group for every call and keep rotating key when end points joins or leave the call, while another app could have a persisted group that can be used for multiple calls and exchange keys with all group endpoints for every call. When a new key material is created during the call, we recommend not to start using it immediately in SFrame to give time for the new keys to be delivered.  If the application supports delivery receipts, it can be used to track if the key is delivered to all other endpoints on the call before using it. Keys must have a sequential id starting from 0 and incremented eery time a new key is generated for this endpoint.  The key id will be added in the SFrame header during encryption, so the recipient know which key to use for the decryption. 4.1. While any other E2EE key management framework can be used with SFrame, there is a big advantage if it is used with MLSARCH which supports group natively and can support very large groups an efficiently.  When MLSPROTO is used, the endpoints keys (AKA Application secret) can be used directly for SFrame without the need to exchange separate key material.  The application secret is rotated automatically by MLSPROTO when group membership changes. </ins> 5.

Discussion:
Rewrite the Key management section Add MLS subsection Update the SFrame format Fixed typos
Change:
(Variable length) The key id value up to 8 bytes long.  Frame counter (CTR): (Variable length) Frame counter value up to 8 bytes long. <del> 3.2. </del> <ins> 3.3. </ins> <del> 3.2.1. </del> <ins> 3.3.1. </ins> Each client creates a 32 bytes secret key K and share it with with other participants via an E2EE channel.  From K, we derive 3 secrets:

Discussion:
Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section
Change:
7. <del> It is possible that middleboxes could use traits of a specific </del> <ins> It is possible that middleboxes could observe traits of a specific </ins> version of QUIC and assume that when other versions of QUIC exhibit similar traits the same underlying semantic is being expressed. There are potentially many such traits; see bad-assumptions.  Some

Discussion:
I can't stop re-reading this text. There isn't much of it, but that makes it easier to spot little annoyances like this.