jiebi/CodeConvo huggingface dataset:
Change:
extension contains a list of MLS ciphersuites that are supported by the client. <ins> These extensions MUST be always present in a ClientInitKey. </ins> 7.2. The "expiration" extension represents the time at which clients MUST

Discussion:
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 7 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 8 issues were created. Of these, 0 issues have been closed and 8 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits.

:hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
Start exchanging media with a given remote peer, and free any resources in the offer that are not being used. <del> 3.7.1. </del> <ins> 3.8.1. </ins> Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one

Discussion:
Fixes URL
LGTM
Updated to incorporate feedback from comments. Some more detail needed in the last para, but the narrative should be complete.
PTAL
LGTM
In WebRTC section 5.1, addTransceiver(), it says 'When setRemoteDescription is called with a corresponding remote description that is able to receive multiple RTP encodings as defined in [JSEP], the RTCRtpSender may send multiple RTP encodings and the parameters retrieved via the transceiver’s sender.getParameters() will reflect the encodings negotiated.' It is not obvious what to use as the JSEP reference because there does not seem to be a single place that talks about receipt of multiple encodings.
The specification of signalling that you can recevie multiple encodings seems to belong in either the RID spec or the JSEP spec. A decision was made some time back that WebRTC entities are only required to support receiving one incoming stream, but all the specs need to be clear on what that means in practice.
I think it makes sense for us to add some text in JSEP for this and create a link
The plan is to add a new section in JSEP section 3 that would give an overview of simulcast, perhaps a summary of URL, section 6.2.
Change:
indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1. To properly indicate use of DTLS, the <proto> field MUST be set to <del> "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8. </del> <ins> "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport. </ins> The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates have yet been

Discussion:
I just rewrote this.
Overall this LG - if you can resolve these nits tonight, great - otherwise let's land it and clean it up later
I don't think I can get to these tonight, but I may be able to get to them tomorrow AM before Cullen does.
lgtm
Change:
A variable-length integer that identifies the frame type. <del> A variable-length integer that describes the length of the Frame Payload. </del> <ins> A variable-length integer that describes the length in bytes of the Frame Payload. </ins> A payload, the semantics of which are determined by the Type field.

Discussion:
Probably a bit overkill, but since it wasn't explicitly stated + I thought we had replaced "octets" with bytes everywhere else.
Change:
"example.org", then the client would provision the following DNS record: <del> The response to the DNS challenge provides the computed key authorization to acknowledge that the client is ready to fulfill this challenge. The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. </del> <ins> A client responds with an empty object ({}) to acknowledge that the challenge can be validated by the server. </ins> <del> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. </del> <ins> On receiving a response, the server constructs and stores the key authorization from the challenge "token" value and the current client account key. </ins> To validate a DNS challenge, the server performs the following steps: <del> Compute the SHA-256 digest FIPS180-4 of the key authorization </del> <ins> Compute the SHA-256 digest FIPS180-4 of the stored key authorization </ins> Query for TXT records for the validation domain name

Discussion:
Respond with {} instead of providing keyAuthorization Remove "keyAuthorization" from the challenge object returned by the server. Fixes a potential misguide for clients that enabels a MitM attack. Keep the storing of the keyAuthorization on response to retain the same behavior if an account key roll-over happens before the challenge is validated
I like this change in theory, but it's substantive enough that I'd like to give the mailing list a couple more pokes to see if anyone has further thoughts on it before we land it.
This is not an editorial change, and I think it would require pushing back further on last-call timing. Please bring this up and discuss on the mailing list; WG consensus will be required.
This was brought up on the list Dec 27th and only positive responses were received.
https://ietf-wg-URL From the spec This is not consistent with the example: Which is posting to . I would expect the example to show has . Also, there is no other mention of present in the example payload. Is this a mistake?
The example is correct. The URL for the challenge is , as shown in the response body above the example you cite: (Note the at the end that distinguishes the challenge from the authz URL ) As for the field, it looks like NAME fixed this in
thanks
This PR looks good to me. I think the proposed change makes sense and removes a potential error without sacrificing anything functionality wise. NAME NAME Can you give this a review as well?
Change:
When a push subscription has been associated with an application server, the request for push message delivery MUST include proof of <del> possession for the associated private key or token that was used when creating the push subscription. </del> <ins> possession for the associated private key that was used when creating the push subscription. </ins> A push service MUST reject a message that omits mandatory credentials with a 401 (Unauthorized) status code.  A push service MAY reject a

Discussion:
This was either in error, or could refer to "JWT" instead.
There are multiple references to a token that are unclear: ...
The first is just a mistake; a relic of a previous version. It can be removed. The second refers to JWT. I'll fix that.
Change:
The version and extensions fields have the same meanings as their corresponding values in the ServerHello.  The server SHOULD send only the extensions necessary for the client to generate a correct <del> ClientHello pair (currently no such extensions exist).  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </del> <ins> ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see cookie) extension. </ins> Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake

Discussion:
I think this aside is out-of-date: extensions cannot be empty, and there are now defined extensions to put here.
Change:
endpoint MAY send a stateless reset in response to receiving a packet that it cannot associate with an active connection. <del> A stateless reset is not appropriate for signaling error conditions. An endpoint that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE frame if it has sufficient state to do so. </del> <ins> A stateless reset is not appropriate for indicating errors in active connections.  An endpoint that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE frame if it is able. </ins> To support this process, a token is sent by endpoints.  The token is carried in the Stateless Reset Token field of a NEW_CONNECTION_ID

Discussion:
Error? / A stateless reset is not appropriate for signaling error conditions./ I understand, but this sentence seems odd to me, is it possible to say /error conditions when there is connection state/ or something like that? Is it worth a cross ref to section 11 to be clear what a “normal” error is? Section 9 NiTs in wording: /Acknowledgments cannot be used for path validation as they contain insufficient entropy/ Acknowledgments cannot be used for path validation because they contain insufficient entropy/ /as endpoints independently determine reachability on each direction of a path./the endpoints independently determine reachability on each direction of a path./ Is it slightly easier to read: / One or more frames are assembled into packets./ / One or more frames are assembled into a QUIC packet./ In section 3.3. It says: /The receiver of a stream sends MAXSTREAMDATA (Section 19.10) and STOP_SENDING frames (Section 19.5)./ Is this a para where ACK frames should also be mentioned? It seemed odd to me that ACKs are not mentioned at some pointy around here.
I think that the intent is to be more general than just "this is not for connection errors". How about: I don't think that we want to talk about acknowledgements at the level of the stream section. They don't affect stream states and this is specifically about what stream-related frames can be sent.
Change:
multiple small Messages can incur high overhead if each needs to be enqueued separately.  To avoid this, the application can indicate a batch of Send actions through the API.  When this is used, the <del> implementation should hold off on processing Messages until the batch </del> <ins> implementation can defer the processing of Messages until the batch </ins> is complete. 5.2.

Discussion:
Section 5.1.2: "the implementation should hold off on processing Messages until the batch is complete" assumes that there is indeed a context-switch penalty. Batch semantics are only for hints to the implementation/protocol stack, and this advice only applies when that hint allows the stack to reduce context switch penalty. Correct? (If so, this should be noted explicitly)
Actually 5.1.3. This reads odd to me, I'd expected myself more like: "When this is used, the implementation can defer the processing Messages until the batch is complete." (eliminating "off on", also from this sentence?)
Agreed, I think your text reads better NAME should it be "... defer the processing of Messages ..." though? I think it also solves the question from NAME as it is now expressed as an opportunity for the implementation.
I believe these are all editorial. First, this list needs some front matter: "protocols should implement each of the following Message Properties on send as follows" or similar. "Ordered" should state that protocols that do not support configurable ordering may ignore the property. "Final" should note that it is not mandatory to close the connection after a Final message. "Corruption Protection Length" should note that it can be ignored basically everywhere but UDP-Lite. One open question: is it an error to send a Message after a Final message, and does the protocol implementation need to handle this itself?
... "Corruption Protection Length" should note that it can be ignored basically everywhere but UDP-Lite. ... In protocols such as UDP-Lite, various tunnels would, DCCP allows, etc.
I think it should be an error to send a Message after a Final message and the implementation of the transport services system should handle it. If it is not an error, then it will fail sometimes and sometimes not depending on if the connection is closed or not, that seems less useful to me.
Change:
All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point. <del> More advice on the use of DSCP code points with RTP is given in I- D.ietf-dart-dscp-rtp. </del> <ins> More advice on the use of DSCP code points with RTP is given in RFC7657. </ins> There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points.  Some of these schemes

Discussion:
o Added a SHOULD NOT about using deprecated temporary IPv6 addresses. o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657
Some systems keep old IPv6 addresses around even when changing to new for privacy. How should we avoid trying the ones that don't make sense to try?
As documented here: URL and here: URL it appears that the implementers claim everything is working as designed on systems which accumulate several temporary deprecated IPv6 addresses. My assumption here is that using deprecated temp addresses as ICE candidates (additionally to the non deprecated temporary address) is not going to increase the likeliness of establishing a connection. So adding these additional ICE candidates only causes extra over head. Therefore adding a warning/clarification statement for implementers to avoid deprecated temporary IPv6 addresses (in case there is usable non-deprecated temporary IPv6 address available) seem appropriate.
Adding warning in -12: "If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses."
Sounds good to me.
Addressed in (version -12)
Change:
RFC4787 requires a network state timeout that is not less than 2 minutes for most UDP traffic.  However, in practice, a QUIC endpoint <del> can experience lower timeouts, in the range of 30 to 60 seconds. </del> <ins> can experience lower timeouts, in the range of 30 to 60 seconds QUIC- TIMEOUT. </ins> In contrast, RFC5382 recommends a state timeout of more than 2 hours for TCP, given that TCP is a connection-oriented protocol with well-

Discussion:
Looks good to me
URL, where does this data come from? any reference will be great here.
NAME is there something we can cite here?
The best public data I'm aware of is slide 10 of: URL
Change:
indicates the willingness of the server to communicate with the client. <del> The QUIC header optionally contains a Connection ID which can be used </del> <ins> The QUIC header optionally contains a connection ID which can be used </ins> as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the <del> Connection ID is present and what length it has.  However, Connection </del> <ins> connection ID is present and what length it has.  However, connection </ins> IDs may be renegotiated during a connection, and this renegotiation <del> is not visible to the path.  Keying state off the Connection ID may </del> <ins> is not visible to the path.  Keying state off the connection ID may </ins> therefore cause undetectable and unrecoverable loss of state in the <del> middle of a connection.  Use of Connection ID specifically </del> <ins> middle of a connection.  Use of connection ID specifically </ins> discouraged for NAT applications. 4.2.

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
Name: The name of the ciphersuite <ins> [[ RFC EDITOR: This section should be the same as the corresponding text in draft-ietf-tls-rfc8447bis.  Please align the two documents if they have diverged in the approval process. ]] </ins> Recommended: Whether support for this ciphersuite is recommended <del> by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> by the IETF MLS WG.  Valid values are "Y", "N", and "D", as described below.  The default value of the "Recommended" column is "N".  Setting the Recommended item to "Y" or "D", or changing a item whose current value is "Y" or "D", requires Standards Action RFC8126. Y: Indicates that the IETF has consensus that the item is RECOMMENDED.  This only means that the associated mechanism is fit for the purpose for which it was defined.  Careful reading of the documentation for the mechanism is necessary to understand the applicability of that mechanism.  The IETF could recommend mechanisms that have limited applicability, but will provide applicability statements that describe any limitations of the mechanism or necessary constraints on its use. N: Indicates that the item has not been evaluated by the IETF and that the IETF has made no statement about the suitability of the associated mechanism.  This does not necessarily mean that the mechanism is flawed, only that no consensus exists. The IETF might have consensus to leave an items marked as "N" on the basis of it having limited applicability or usage constraints. D: Indicates that the item is discouraged and SHOULD NOT or MUST NOT be used.  This marking could be used to identify mechanisms that might result in problems if they are used, such as a weak cryptographic algorithm or a mechanism that might cause interoperability problems in deployment. </ins> Reference: The document where this ciphersuite is defined

Discussion:
... by just importing the . NAME lmk if you think we should reference instead.
The consensus in saag was to expand Recommended to include "D" to RFC 8447bis. Should probablly do the same here.
Change:
2.6.2. <del> The following implicit type conversion may occur: </del> <ins> Just as queries can be used in logical expressions by testing for the existence of at least one node (extest), a function expression of declared type "NodesType" can be used as a function argument for a parameter of declared type "LogicalType", with the equivalent conversion rule: </ins> <del> Where an instance of "NodesType" needs to be converted to a "LogicalType", the conversion proceeds as follows: </del> <ins> If the nodelist contains one or more nodes, the conversion result is "LogicalTrue". </ins> <del> If the nodelist contains one or more nodes, the conversion result is "LogicalTrue". </del> <ins> If the nodelist is empty, the conversion result is "LogicalFalse". </ins> <del> If the nodelist is empty, the conversion result is "LogicalFalse". Given an expression with a declared type of "NodesType", a "ValueType" can be obtained using a function such as "value()" (see value). </del> <ins> Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined.  A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension such as "value" (see value). </ins> The well-typedness of function expressions can now be defined in terms of this type system.

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)