jiebi/CodeConvo huggingface dataset:
Change:
Update the ratchet tree by replacing nodes in the direct path from the removed leaf using the information in the Remove message <del> Reduce the size of the roster and the tree until the rightmost element roster element and leaf node are non-null </del> Update the ratchet tree by setting to blank all nodes in the <del> direct path of the removed leaf </del> <ins> direct path of the removed leaf, and also setting the root node to blank Truncate the roster such that the last roster element is non-null Truncate the tree such that the rightmost non-blank leaf is the last node of the tree Note that, in step 4, there must be at least one non-null element in the roster, since any valid GroupState must have the current member in the roster and self-removal is prohibited.  The same reasoning justifies the existence of a non-blank leaf in the ratchet tree in step 5. </ins> The update secret resulting from this change is the path secret computed for the root node of the ratchet tree in the first step.

Discussion:
This clears up the wording around how to prune the ratchet tree on a Remove operation. Previously, it could be interpreted as "remove nodes from the tree until the rightmost node is not null", but this is not what is intended by the authors, and it also has the ability to produce invalid trees (i.e., trees with an even number of elements). The second change is to do the truncation after doing the Blank propogation up the direct path of the removed leaf. Note that the order of these steps doesn't matter in that they produce the same resulting tree. However, if we blank after pruning, an implementor would have to take care to not to try to blank out previously-removed nodes. Prune-then-blank is a little easier to reason about. The third change is a semantic fix. It is clear from the last paragraph in this section that the root node should be blanked, but the text only said to blank the direct path of the leaf, which does not include the root node. I just added that part in.
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:
start position, an end position, and possibly a step value that moves the position from the start to the end (slice). <del> JSONPath employs an for computing values and making decisions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform.  JSONPath can use such expression language expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in [no-dot-length]: The symbol "@" is used for the current node, i.e., the node in the context of which the expression is evaluated. </del> Filter expressions are supported via the syntax "?(<boolean expr>)" as in

Discussion:
There does not seem to be an appetite for doing the necessary spec work. This PR will test that assertion. Filter expressions are still supported, but not "container expressions", of the form [(...)].
I think this can be added later, similar to the consensus for . Personally I still see value in having it.
Change:
(IPv4), the DF bit MUST be set if possible, to prevent fragmentation on the path. <del> Datagrams are required to be of a minimum size under some conditions. However, the size of the datagram is not authenticated.  Therefore, an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints, though the endpoint MAY discard such datagrams. </del> <ins> QUIC sometimes requires datagrams to be no smaller than a certain size; see version-negotiation as an example.  However, the size of a datagram is not authenticated.  That is, if an endpoint receives a datagram of a certain size, it cannot know that the sender sent the datagram at the same size.  Therefore, an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints; the endpoint MAY however discard such datagrams. </ins> 14.1.

Discussion:
NAME I think you missed the change proposed to the reference. It should point to somewhere that imposes minimum datagram size (e.g., {{validate-handshake}}, not {{version-negotiation}}).
Urgh. Thanks for catching that, NAME sent.
([IPv4]), the DF bit MUST be set if possible, to prevent fragmentation on the path. However, the size of the datagram is not authenticated. Therefore, an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints, though the endpoint MAY discard such datagrams. I really think this section needs re-writing for clarity.
I find this text perfectly clear, so I will need help in identifying in what ways the text lacks clarity.
Other than kazuho's nit which I regard as minor, this is good.
Change:
If the server selects a PSK cipher suite, it MUST send a "pre_shared_key" extension with the identity that it selected.  The client MUST verify that the server's selected_identity is within the <del> range supplied by the client.  If any other value is returned, the client MUST generate a fatal "unknown_psk_identity" alert and close the connection. </del> <ins> range supplied by the client.  If the server supplies an "early_data" extension, the client MUST verify that the server selected the first offered identity.  If any other value is returned, the client MUST generate a fatal "unknown_psk_identity" alert and close the connection. Note that, although 0-RTT data is encrypted with the first PSK identity, the server may fall back to 1-RTT and select a different PSK identity if multiple are offered. </ins> 6.3.2.6.

Discussion:
I would actually much rather we only offer one PSK identity since TLS 1.2 was perfectly fine offering just one and resumption has no use for offering multiple, but I suspect I will lose that fight. Absent that, at least make the protocol well-defined. Unlike both TLS 1.2 resumption and TLS 1.2 PSK, TLS 1.3 increases the state space and allows clients to offer multiple PSK identities. This mostly works, but 0-RTT presumes that only one is offered. Define 0-RTT to presume the first identity is selected and clarify that other shapes are possible due to the increased state space.
Change:
this specification an implementation of XSD 1.0 regexps is equivalent to an implementation of XSD 1.1 regexps. <del> 5.2. </del> <ins> 5.3. </ins> Perform the following steps on an I-Regexp to obtain an ECMAScript regexp ECMA-262:

Discussion:
Signed-off-by: Tim Bray Based on our email thread with James, and a couple of minor editorial touch-ups.
LGTM, thanks.
Change:
mmusic-sctp-sdp, Section 4.1. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", <del> "a=ice-options", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc- datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del> <ins> "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp- port" line referencing the SCTP port number as defined in I-D.ietf- mmusic-sctp-sdp, Section 4.1. </ins> Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in RFC5888.  This attribute MUST

Discussion:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.
Change:
support removing a Message from its buffer, this property may be ignored. <del> Niceness: this represents the ability to de-prioritize a Message in favor of other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different niceness on streams of different priority. </del> <ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different Priority on streams of different priority. </ins> Ordered: when this is false, it disables the requirement of in- order-delivery for protocols that support configurable ordering.

Discussion:
Not many text fixes needed - quite a bit of text reflected the old choice of Priority anyway and wasn't correctly updated for Niceness :-)
At 8.1.2 you say lower values have higher priorities for connPrio. But later, at msgPrio, higher values have higher priority, and in the examples where you speak of the interaction of connPrio and msgPrio, you imply that higher means higher for both properties. Please check for consistency and clarify.
Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this, e.g. PR which I don't know... too many iterations have mangled the text.
Aha, now I see what happened: following some more PRs, also , in PR , NAME re-introduced some text saying that sends on Connections with lower-priority values will be prioritized over sends on Connections with a higher-priority value. This reverses the logic for some part of the text - I suspect that NAME (very understandably!) forgot what happened and this created this mix. We have been editing these documents for way too long!
Fine with me. The max_prio problem can be addressed separately.
Change:
The server provides the following fields as part of the challenge: <del> The string "proofOfPossession-01" </del> <ins> The string "proof-of-possession-01" </ins> An array of certificates, in Base64url-encoded DER format, that contain acceptable public keys.

Discussion:
awesome thanks :+1:
Any reason for the inconsistent naming of the challenge types? Specifically vs Wouldn't it make sense to stick to dash delimited words? or just camelCase, not that it matter as long as its consistent. I would personally avoid camelcase in that context since there is already a lot acronyms.
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.

Discussion:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.
Change:
9.5. The following registration is done for the CWT Confirmation Methods <del> Registry following the procedure specified in section 7.2.1 of I- D.ietf-ace-cwt-proof-of-possession: </del> <ins> Registry following the procedure specified in section 7.2.1 of RFC8747: </ins> Confirmation Method Name: "osc" Confirmation Method Description: OSCORE_Security_Context carrying

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:
32 bytes generated by a secure random number generator.  See implementation-notes for additional information.  The last eight bytes MUST be overwritten as described below if negotiating TLS <del> 1.2 or TLS 1.1.  This structure is generated by the server and MUST be generated independently of the ClientHello.random. </del> <ins> 1.2 or TLS 1.1, but the remaining bytes MUST be random.  This structure is generated by the server and MUST be generated independently of the ClientHello.random. </ins> The single cipher suite selected by the server from the list in ClientHello.cipher_suites.  A client which receives a cipher suite

Discussion:
by Hugo Krawczyk.
Other than davegarrett's editorial notes, this looks good.
Change:
IETF Review for the last), are appropriate for these one-byte code points because of their scarcity. <del> This document proposes no changes to the EC Curve Type, EC Point Format, and Supported Groups Registries (see I-D.ietf-tls- rfc4492bis). </del> 3. IANA is to update the names of the following registries to add "TLS"

Discussion:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.
Change:
Frame types of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored (extensions).  These frames have no semantics, and <del> can be sent on any open stream when application-layer padding is desired.  They MAY also be sent on open streams in connections where no data is currently being transferred.  Endpoints MUST NOT consider these frames to have any meaning upon receipt. </del> <ins> MAY be sent on any stream where frames are allowed to be sent.  This enables their use for application-layer padding.  Endpoints MUST NOT consider these frames to have any meaning upon receipt. </ins> The payload and length of the frames are selected in any manner the implementation chooses.

Discussion:
NAME does this address your concerns?
Section 7.2.8: URL These frames have no semantics, and can be sent on any open stream when application-layer padding is desired. So I am uncertain if it is acceptable to shoehorn in a reserved frame after a frame that is supposed to be the last and then result in a close of the frame? Based on what is written I would lean to the interpretation that it is allowed, as the frame sender has decided to not close the stream yet, and thus it is open. If this is correct interpretation than it is up to the editor if they like to clarify more. Else something needs to be done.
The best example here is sending a reserved frame after a Request stream is opened by the client. Perhaps it is useful to call that out in section 4.1. is a bit loose. You can't send frames on qpack streams for instance, or as the first bytes on a push stream. Maybe we can rephrase it as, "Can be sent on any stream where frames are permitted to be sent"
There are no frames that close the stream, because stream closure is handled by the transport. SETTINGS is special in that it is required to be first, and is covered by : It would hypothetically apply to a future frame type which is required to come at the end of the stream as well, but we have no such frames at this time. ( does impose specific ordering on DATA and HEADERS frames relative to each other, but says nothing about other frame types.) NAME point is well-taken, and I'll take that text.
NAME does the PR address your issue?
Yes, I think this PR clarifies things a bit and are sufficient to resolve my issue.
Labeling this as "editorial" based on
Change:
Responses may be returned in a different temporal order than requests were made using the protocols native multi-streaming functionality. <del> A DNS response may contain a set of DNS Resource Records each with its own Time To Live (TTL) freshness information.  The freshness lifetime (RFC7234 Section 4.2) of the HTTP response should be coordinated with the Resource Record bearing the smallest TTL in the response.  The freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </del> <ins> The Answer section of a DNS response contains one or more RRsets. (RRsets are defined in RFC7719.)  According to RFC2181, each resource record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can have different TTLs.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  The HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The response freshness lifetime MUST NOT be greater than that indicated by the DNS Record with the smallest TTL in the response. </ins> A DNS API Client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic

Discussion:
… issue
It is not stated crystal clear in the -01 draft if there's only one DNS packet per HTTP request or if it is allowed to send more than one. Some wordings (like ) suggest a single packet. I think it would benefit the document to be more explicit on this detail.
good point - it is meant to be one, otherwise blocking and reordering (which is resolved at the intra-request http level) would be a problem. we'll add text.
Change:
One way of thinking of this is as if specialization is a stateful compression layer between the handshake and the record layer: <del> Specializations are defined by a "compression profile" that specifies what features are to be optimized out of the handshake.  In the following subsections, we define the structure of these profiles, and how they are used in compressing and decompressing handshake messages. </del> <ins> By assuming that out-of-band agreements took place already prior to the start of the cTLS protocol exchange, the amount of data exchanged can be radically reduced.  Because different clients may use different compression templates and because multiple compression templates may be available for use in different deployment environments, a client needs to inform the server about the profile it is planning to use.  The profile field in the ClientHello serves this purpose. </ins> <del> 5.1. </del> <ins> Although the template-based specialization mechanisms described here are general, we also include specific mechanism for certificate-based exchanges because those are where the most complexity and size reduction can be obtained.  Most of the other exchanges in TLS 1.3 are highly optimized and do not require compression to be used. </ins> <del> A compression profile defining of a specialized version of TLS is defined using a JSON dictionary.  Each axis of specialization is a key in the dictionary.  [[OPEN ISSUE: If we ever want to serialize this, we'll want to use a list instead.]]. </del> <ins> The compression profile defining the use of algorithms, algorithm parameters, and extensions is specified via a JSON dictionary. </ins> For example, the following specialization describes a protocol with a single fixed version (TLS 1.3) and a single fixed cipher suite

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:
packet and some also include an Initial packet. Datagrams that contain a QUIC Initial Packet (Client Hello, Server <del> Hello, and some Initial Completion) must be at least 1200 octets long.  This protects against amplification attacks and verifies that the network path meets minimum Maximum Transmission Unit (MTU) requirements.  This is usually accomplished with either the addition of PADDING frames to the Initial packet, or coalescing of the Initial Packet with packets from other encryption contexts. </del> <ins> Hello, and some Initial Completion) contain at least 1200 octets of UDP payload.  This protects against amplification attacks and verifies that the network path meets the requirements for the minimum QUIC IP packet size, see Section 14 of QUIC-TRANSPORT.  This is accomplished by either adding PADDING frames within the Initial packet, coalescing other packets with the Initial packet, or leaving unused payload in the UDP packet after the Initial packet.  A network path needs to be able to forward at least this size of packet for QUIC to be used. </ins> The content of QUIC Initial packets are encrypted using Initial Secrets, which are derived from a per-version constant and the

Discussion:
This seeks to address issue: "MTU or Min QUIC Packet Size? "
Sect 2.4: says: “the network path meets minimum Maximum Transmission Unit (MTU) requirements. “ There is text in the QUIC transport spec that the WG perfected a little in the final stages, and I think this use of MTU in sect 2.3 is suspect. As I see it, the requirements in QUIC are for a minimum supported QUIC packet size... not the MTU required to send this on an interface. ... This nuanced might be a really important detail for operations staff - where there is frequently a need to consider encapsulations and tunnels on interfaces of devices. ... A cross reference to the QUIC Spec may also help here.
NAME can you propose text?
Thought to be addressed in PR
PR merged
I think there are only 3 ways to fill up the space, so maybe enumerate them? I also wonder if we need to caution against stripping unused UDP payload or splitting up packets within a UDP datagram?