jiebi/CodeConvo huggingface dataset:
Change:
constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in <del> IANA.  External PSKs MUST NOT be imported for versions of (D)TLS 1.2 or prior versions.  See rollout for discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist for </del> <ins> IANA.  External PSKs MUST NOT be imported for (D)TLS 1.2 or prior versions.  See rollout for discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist for </ins> incremental deployment. ImportedIdentity.context MUST include the context used to derive the

Discussion:
Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
Change:
6.1. <del> This creates a "Vapid Authentication Scheme Parameters" registry for parameters to the "vapid" authentication scheme.  This registry is under the "WebPush Parameters" grouping.  The registry operates on the "Specification Required" policy RFC5226. </del> <ins> This document creates a "Vapid Authentication Scheme Parameters" registry for parameters to the "vapid" authentication scheme.  This registry is under the "WebPush Parameters" grouping.  The registry operates on the "Specification Required" policy RFC5226. </ins> Registrations MUST include the following information:

Discussion:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.
Change:
error message to requests received that correspond to a Security Context with an expired token. <del> If the exchange was an update of access rights, i.e., a new Security Context was derived from a client that already had a Security Context in place, the RS is RECOMMENDED to delete the old Security Context after OSCORE verification and verification of access rights succeed. The RS MUST delete the Security Context if it deletes the access token associated to it.  If the exchange was an update of access rights, i.e., a new Security Context was derived from a client that already had a Security Context in place, the RS is RECOMMENDED to delete the old Security Context after OSCORE verification succeeds. The RS MUST delete the Security Context if it deletes the access token associated to it. </del> 4.4. The RS MUST follow the procedures defined in section 5.8.2 of I-

Discussion:
OCF comments.
check that re-sending token triggers nonces exchange and new security context derived.
add a implementation note about namespaces for identifiers in case several methods are used (EDHOC, ACE, others)
Change:
not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. <ins> If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:

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:
1.4.1. The root node identifier "$" refers to the root node of the argument, <del> i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. </del> <ins> i.e., to the argument as a whole. </ins> The current node identifier "@" refers to the current node in the context of the evaluation of a filter expression (described later).

Discussion:
Fixes URL
Section 1.4 says: >A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more selectors. So this includes relative paths (starting with ). However, section 1.4.1 contradicts this: Similarly, section 2.4 says: >Every JSONPath query MUST begin with the root identifier . (Remember that, according to our terminology, "query" is a short name for a JSONPath expression.) A possible solution is for sections 1.4.1 and 2.4 to talk about JSONPath expressions/queries which do not appear inside a filter expression.
Change:
Greasing the QUIC Bit <del> draft-ietf-quic-bit-grease-latest </del> Abstract This document describes a method for negotiating the ability to send <del> an arbitrary value for the second-to-most significant bit in QUIC </del> <ins> an arbitrary value for the second-most significant bit in QUIC </ins> packets. 1. <del> QUIC QUIC intentionally describes a very narrow set of fields that are visible to entities other than endpoints.  Beyond those characteristics that are defined as invariant QUIC-INVARIANTS, very little about the "wire image" RFC8546 of QUIC is visible. </del> <ins> The version-independent definition of QUIC QUIC-INVARIANTS intentionally describes a very narrow set of fields that are visible to entities other than endpoints.  Beyond those characteristics that are invariant, very little about the "wire image" RFC8546 of QUIC is visible. </ins> <del> The second-to-most significant bit of the first byte in every QUIC </del> <ins> The second-most significant bit of the first byte in every QUIC </ins> packet is defined as having a fixed value in QUIC version 1 QUIC. The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see DEMUX for a

Discussion:
These are all the changes I found from the text diff, plus some extra changes about versions.
I have reviewed the changes, and I agree that they are editorial in nature.
Change:
"array" in particular do not take on a generic meaning, such as they would in a general programming context. <del> Additional terms used in this specification are defined below. </del> <ins> Additional terms used in this document are defined below. </ins> 1.1.1. <del> This specification models the argument as a tree of JSON values, each with its own node.  A node is either the root node or one of its </del> <ins> This document models the argument as a tree of JSON values, each with its own node.  A node is either the root node or one of its </ins> descendants. <del> This specification models the result of applying a query to the argument as a nodelist (a list of nodes). </del> <ins> This document models the result of applying a query to the argument as a nodelist (a list of nodes). </ins> So nodes are the selectable parts of the argument.  The only parts of an object that can be selected by a query are the member values.

Discussion:
Generally, use "this document" rather than "this specification". Then use the term specification judiciously. Prefer the term "language" to "platform".
Yep, environment is a nice synonym of platform. Thank you for addressing my concern!
Change:
records.  This admits the possibility that the extension might not be negotiated when a connection is renegotiated or resumed. <ins> The record size limit can interact with the maximum transmission unit (MTU) in DTLS, but it is a separate and independent constraint on record size.  In particular, it is not appropriate to use the record size limit in place of path MTU detection.  The record size limit is a fixed property of an endpoint that is set during the handshake and fixed thereafter.  In comparison, the MTU is determined by the network path and can change dynamically over time. </ins> 4.1. The size limit expressed in the "record_size_limit" extension doesn't

Discussion:
Add an applicability statement. This only addresses buffer space issues, not processing or bandwidth constraints. I didn't observe (in the introduction) that this can negatively affect bandwidth, that's later. Hannes also observed that we don't really talk about the path MTU. I made it clear that these are separate and independent limitations. For NAME
Thanks for providing this text. While I had been hoping for more clarifications about the interactions between the MTU information entering the stack from below and the RSL parameter passed to the stack from the application side I think it is a good start.
Oh, also, I have moved the intro text down a paragraph. I think that it is better to talk about the properties of this extension rather than focus more on what MFL does or doesn't do.
Change:
transcript of group operations, using the transcript hash from the provisional GroupState object: <del> [[ OPEN ISSUE: The confirmation data and signature data should probably cover the same data as the one we cover with the GroupState. ]] </del> HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. Sign uses the signature algorithm indicated by the signer's credential in the roster. <del> [[ OPEN ISSUE: The Add and Remove operations create a "double-join" situation, where a member's leaf key is also known to another client. When a member A is double-joined to another B, deleting A will not remove them from the conversation, since they will still hold the leaf key for B.  These situations are resolved by updates, but since operations are asynchronous and members may be offline for a long time, the group will need to be able to maintain security in the presence of double-joins. ]] </del> [[ OPEN ISSUE: It is not possible for the recipient of an handshake message to verify that ratchet tree information in the message is accurate, because each node can only compute the secret and private

Discussion:
Clean up some OPEN ISSUES that aren't open any more Make the welcome/add diagram clearer
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 1 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 4 comments. - - Last week, 9 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - 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:
1. <del> The Privacy Pass protocol as described in draft-davidson-pp-protocol can be integrated with a number of different settings, from server to server communication to browsing the internet. </del> <ins> The Privacy Pass protocol as described in draft-ietf-privacypass- protocol can be integrated with a number of different settings, from server to server communication to browsing the internet. </ins> In this document, we will provide an API to use for integrating Privacy Pass with an HTTP framework.  Providing the format of HTTP

Discussion:
Initial work for fixing .
NAME
As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have. cc NAME NAME
Yeah, this likely needs to be embedded both into the Architecture draft for the generic concept of a context, and then an actual instantiation of redemption contexts in the HTTP API doc.
Yep should we split out the HTTP work into a separate issue?
Thanks NAME This looks good, I have mostly just a few nits to resolve.
Change:
in Base 64 with URL and filename safe alphabet with no padding, as specified in sections 5 and 3.2 of RFC4648.  If the aggregator does not recognize the task ID, then it responds with HTTP status code 404 <del> and an error of type "unrecognizedTask".  The aggregator responds to well-formed requests with HTTP status code 200 OK and an "HpkeConfig" value: </del> <ins> Not Found and an error of type "unrecognizedTask".  The aggregator responds to well-formed requests with HTTP status code 200 OK and an "HpkeConfig" value: </ins> [TODO: Allow aggregators to return HTTP status code 403 Forbidden in deployments that use authentication to avoid leaking information

Discussion:
All of the following are currently used to refer to 200 responses: status 200 HTTP 200 OK HTTP status 200 HTTP status 200 OK Would be nice to pick one and use it consistently.
I didn't check if this change is complete, in the sense of making all the language in the doc consistent, but it's at least self-consistent. !
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the variable-length integer encoding from QUIC- TRANSPORT.

Discussion:
This includes all the updates to references in transport. This includes new code again. See URL It would be possible to cite BCP38 as an RFC and avoid this, but I think that the BCP reference is correct. Not as sure about the BCP145 reference, as we need to point to the RFC directly to get the section reference, but I think that is OK on balance.
Change:
watch for increasing numbers of end users uploading significant amounts of content. <del> 2.6. </del> <ins> 2.7. </ins> The causes of unpredictable usage described in sec-unpredict were more or less the result of human choices, but we were reminded during

Discussion:
This definitely needs more work!
NAME and NAME - I have three notes in the section I've added. I'll hit this again later in the week, but if you can express opinions about any of them, that would be very helpful.
NAME In the call we discussed this and we feel like we don't need to say anything about this in addition to what we already said in Section titled "Bitrate Detection Challenges". So, maybe we can drop and close this?
I actually like NAME suggestions - let me spend a couple of hours on this, and then you two can either merge it or reject it.
NAME and NAME see what you think. I'm also ok with closing as wontfix, but wanted to give it a try.
NAME and NAME any thoughts on this PR? I tried to reflect Jake's high-level comments, which were even more helpful and actionable than usual ...
This reads much better than the initial version, thanks.
Pulling the TBD out of the draft text and capturing it here instead. Suggestion from mic at IETF 106 (Mark Nottingham) in response to call for help on capturing the mismatch between supply and demand of bandwidth with regard to video: Dive into the different constraints coming from different parts of the network or distribution channels. (regarding questions about how to describe the disconnect between demand vs. capacity, while keeping good archival value.) "These are big numbers, but the internet has grown over time, and CDN capacities have grown over time. Is it last mile? Probably not--Is it middle mile? Maybe that's more interesting. It it CPU? Is it network cards? Is it the economics of your peering relationships? Unpicking those bits might help a bit. URL
For many, poor Wifi is the culprit. For many others, the ISP aggregation links are the culprit during the prime times (since most such links are oversubscribed/oversold). For some, the CDN issues create problems and for rare cases, the origin drowns and everybody gets upset. For certain environments like student dorms, campus networks, libraries, airport cafes, it is just lack of bandwidth for the power users.
Thanks, this version reads much better to me. I have no objections.
Change:
encoding, so for example if the target_host is "2001:db8::42", it will be encoded in the URI as "2001%3Adb8%3A%3A42". <del> A payload within a UDP proxying request message has no defined semantics; a UDP proxying request with a non-empty payload is malformed. </del> <ins> By virtue of the definition of the Capsule Protocol (see HTTP-DGRAM), UDP proxying requests do not carry any message content.  Similarly, successful UDP proxying responses also do not carry any message content. </ins> Responses to UDP proxying requests are not cacheable.

Discussion:
"A payload within a UDP proxying request message has no defined semantics; a UDP proxying request with a non-empty payload is malformed." "payload" here I assume is HTTP message content?
Already discussed in and fixed in
... or "message content" There's a lot of uses of UDP payload that do not qualify here. The one example I can see that would benefit from a change is please check if there are any other cases though.
Change:
A server MAY send one or more PUSH_PROMISE frames (frame-push- promise) before, after, or interleaved with the frames of a response message.  These PUSH_PROMISE frames are not part of the response; see <del> server-push for more details.  These frames are not permitted in pushed responses; a pushed response that includes PUSH_PROMISE frames </del> <ins> server-push for more details.  PUSH_PROMISE frames are not permitted on push streams; a pushed response that includes PUSH_PROMISE frames </ins> MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. Frames of unknown types (extensions), including reserved frames

Discussion:
These are some minor editorial things that should be considered to be addressed: Section 4.1: "A server MAY send one or more PUSHPROMISE frames (Section 7.2.5) before, after, or interleaved with the frames of a response message. These PUSHPROMISE frames are not part of the response; see Section 4.4 for more details. These frames are not permitted in pushed responses; a pushed response that includes PUSHPROMISE frames MUST be treated as a connection error of type H3FRAMEUNEXPECTED." Especially the third sentence was hard to parse. Took me a while to realize that it tries to express that PUSHPROMISE frames are not allowed in pushed responses. I think it is primarily a language thing. However, isn't this dependent on stream type. So PUSHPROMISE are allowed on the client-initiated bi-directional stream but not on the server-initiated unidirectional stream. Section 4.1.1: "For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at URL" To avoid more confusion like the one I had in IETF last call. Can you add an Editors note (to be removed before RFC publication) that this registry does not yet exist, and is dependent on approval of [SEMANTICS]? Section 7.2.4.1: "SETTINGSMAXFIELDSECTION_SIZE (0x6): The default value is unlimited. See Section 4.1.1 for usage." As the actual discussion of usage of this setting is in Section 4.1.1.3 wouldn't that be better to reference?
I'll take a look at cleaning it up, but I'm hesitant to simply say "can't be used on unidirectional streams" because an extension might create a unidirectional stream that does allow PUSH_PROMISE frames for whatever reason. Maybe specifically stating that they can't be sent on Push Streams would work? Good suggestion. Good suggestion; probably we moved this text to subsections after the reference was written.
My personal view has been that PUSHPROMISE is part of a request message. And so it has to abide by the rules there. Any attempt to change that requires a semantic extension to H3. Which is what URL precisely does in order to allow PUSHPROMISE on a new stream type.
Change:
Remote Endpoint: The Remote Endpoint represents the application's identifier for a peer that can participate in a transport <del> connection.  For example, the combination of a DNS name for the </del> <ins> connection; for example, the combination of a DNS name for the </ins> peer and a service name/port. Local Endpoint: The Local Endpoint represents the application's <del> identifier for itself that it uses for transport connections.  For </del> <ins> identifier for itself that it uses for transport connections; for </ins> example, a local IP address and port. Selection Properties: The Selection Properties consist of the

Discussion:
Note that Security Considerations and Acknowledgments changes are newline-rewrap only.
Change:
Note: This ordering of the results for the "$..[*]" and "$..*" examples above is not guaranteed, except that: <del> "{o: {"j": 1, "k": 2}, a: [5, 3]}" must appear before "{"j": 1, "k": 2}" and "[5, 3]", </del> <ins> "{"o": {"j": 1, "k": 2}, "a": [5, 3]}" must appear before "{"j": 1, "k": 2}" and "[5, 3]", </ins> "{"j": 1, "k": 2}" must appear before "1" and "2",

Discussion:
Ref: URL
we need to discuss the descendant selector's behavior by including itself to the node list.
Yes. Let's do that in a PR for URL
yes ... it's illustratively shown, what a good thing inline examples are ...
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.