jiebi/CodeConvo huggingface dataset:
Change:
ClientHello compatibility with previous versions of TLS.  Servers MUST ignore unrecognized extensions. <ins> All versions of TLS allow extensions to optionally follow the compression_methods field as an extensions field.  TLS 1.3 ClientHello messages always contain extensions (minimally, "supported_versions" or they will be interpreted as TLS 1.2 ClientHello messages), however TLS 1.3 servers might receive ClientHello messages without an extensions field from prior versions of TLS.  The presence of extensions can be detected by determining whether there are bytes following the compression_methods field at the end of the ClientHello.  Note that this method of detecting optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined.  TLS 1.3 servers will need to perform this check first and only attempt to negotiate TLS 1.3 if a "supported_version" extension is present.  If negotiating a version of TLS prior to 1.3, a server MUST check that the message either contains no data after legacy_compression_methods or that it contains a valid extensions block with no data following.  If not, then it MUST abort the handshake with a "decode_error" alert. </ins> In the event that a client requests additional functionality using extensions, and this functionality is not supplied by the server, the <del> client MAY abort the handshake.  Note that TLS 1.3 ClientHello messages always contain extensions (minimally they must contain "supported_versions" or they will be interpreted as TLS 1.2 ClientHello messages).  TLS 1.3 servers might receive ClientHello messages from versions of TLS prior to 1.3 that do not contain extensions.  If negotiating a version of TLS prior to 1.3, a server MUST check that the message either contains no data after legacy_compression_methods or that it contains a valid extensions block with no data following.  If not, then it MUST abort the handshake with a "decode_error" alert. </del> <ins> client MAY abort the handshake. </ins> After sending the ClientHello message, the client waits for a ServerHello or HelloRetryRequest message.

Discussion:
This tweaks some text in ClientHello with regard to handling the extensions field. The two blocks of text on it in this section are merged together, dropping a little repeated information and putting it in one paragraph after definition of the relevant field instead of covering this in two places in the same section.
Change:
100 <del> This Property is a non-negative integer representing the relative inverse priority (i.e., a lower value reflects a higher priority) of </del> <ins> This Property is a non-negative integer representing the priority of </ins> this Connection relative to other Connections in the same Connection <del> Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in the same Connection Group.  No guarantees of a specific behavior regarding Connection Priority are given; a Transport Services system may ignore this property.  See priority-in-taps for more details. </del> <ins> Group.  A higher value reflects a higher priority.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in the same Connection Group. No guarantees of a specific behavior regarding Connection Priority are given; a Transport Services system may ignore this property.  See priority-in-taps for more details. </ins> 8.1.3.

Discussion:
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!
LGTM.
Change:
from the client's resumption ticket and enable rejecting Early Data based on that information. <del> In either role, applications need to be able to: </del> <ins> In either role, an application protocol can: </ins> configure minimum values for the initial number of permitted streams of each type, as communicated in the transport parameters

Discussion:
The strong requirements here were wrong. What is necessary from these sections is defining operations in QUIC that application protocols can depend on being present. Levying the requirement on implementations was incorrect. As some application protocols don't use certain QUIC features, it is not necessary to require implementations to support features if they are not general purpose. This rephrases these requirements without normative language, instead concentrating on what services the application protocol can depend on. This translates into requirements on implementations, but only via the application protocols they intend to support.
S 5.4 requires that the application be able to control resource allocation of various types, including flow control and the number of permitted streams of each type; This seems like a good idea, but it seems like one could have a reasonable QUIC stack that did not do this.
I would prefer to leave this. Noting that the level of control is not specified. This also suggests that the stack provide a keep-alive control, but there are likely cases (I'm thinking here of DNS over QUIC) where that is unlikely to be a useful feature. The goal is to list things that the specification believes a generic stack will provide. Maybe we could avoid the implication that such an implementation is incomplete by saying that specialized implementations might provide less than a complete API.
NAME willing to fight for this one?
After discussing with editors, we think that it would be better to remove the MUST in this section and say something like: "A general purpose QUIC implementation provides the following functions:" and add "A specialized implementation might provide a subset of these." The same applies to the stream operations.
I think that is a positive change. Borderline design issue by the sound of it. It would be good to see the PR once its available.
Change:
ETSI: European Telecommunications Standards Institute; <del> FEC: Forward Erasure Correction; </del> <ins> FEC: Forward Error Correction; </ins> FLUTE: File Delivery over Unidirectional Transport;

Discussion:
ACM : Adaptative Coding and Modulation; -- Adaptive. This error repeats. CPE: Customer Premise Equipment; -- Premises. (My premise is that this is unfortunate.) FEC: Forward Erasure Correction;-- FEC is traditionally Error. Redefining industry terms to suit your network coding case won't help. FLUTE: File Delivery over Unidirectional Transport;-- just ref RFC6726. bit of a pointless inclusion imo. PEP: Performance Enhanced Proxy [RFC3135]-- the title of RFC3135 is perfectly clear that it's Enhancing and the word 'Enhanced' does not appear in that document. This is not the sort of thing WGLC is for. PLFRAME - see below. Odd to see mention of PLFRAME but not FECFRAME, which is a more direct translation of the packet data.
I have corrected the accronyms in PR We do not mention FECFRAME because it is an internal format and we focus on what is exchanged between access and physical gateways.
Change:
Insecure delegation Instance Iterative mode <ins> Iterative query Iterative resolution </ins> K Key signing key (KSK)

Discussion:
…erative resolution
Agree with your fix to the definition.
During the lead-up to RFC 7719, Tony Finch asked for four terms to be defined: Recursive query Non-recursive query Iterative query Iterative resolution The were not in RFC 7719 but could be in the -bis.
Updated the document in URL
I don't think iterative query is a synonym. I think an iterative query is a non-recursive query that happens to be a query in a series of recursive queries but that is itself not a recursive query. No? That seems more consistent with the iterative resolution definition that follows.
Change:
limits specified in RFC5245, Section 15.4. tls-id value, which MUST be set according to I-D.ietf-mmusic- <del> dtls-sdp, Section 5.  If this is a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values.  If this is an answer, the tls-id value, if present, MUST be the same as in the offer. </del> <ins> dtls-sdp, Section 5.  If this is a re-offer or a response to a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. </ins> DTLS setup value, which MUST be set according to the rules specified in RFC5763, Section 5 and MUST be consistent with the

Discussion:
In section 5.10, the text that says to tear down the old TLS connections seems like it needs a tweek. For the case of a PR_ANS, I would expect it to not get torn down until the resources are freed when the ANS happens.
See: URL
We had a call to discuss and I think reached resolution on the SDP issue. I will prepare a PR and send to the list for approval. Separately we need to close on tls-id size, but that need not hold JSEP if we are willing to have the examples use the longer size (which we all agree is permitted)
Update: we had a call to discuss this and I think have resolution on the SDP semantics. I will prepare a PR for that and send to lists. Separately, we have to discuss the S
JSEP says: values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. But tls-ids are independently generated on each side.
Examples/example generator will also need to get tweaked
Change:
For X25519 and X448, see RFC7748. <ins> 7.3.4. RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  This document replaces the PRF with HKDF, thus requiring a new construction.  The exporter interface remains the same, however the value is computed as: Note: the inner HKDF-Extract is strictly unnecessary, but it maintains the invariant that HKDF Extract and Expand calls are paired. </ins> 8. 8.1.

Discussion:
NAME sanity check?
This isn't going to change a great deal, but we need to identify how exporters are constructed with the change to a HKDF-based PRF and the new key schedule.
Change:
Origin and Issuer model, the Issuer accepts token requests that come from trusted Attesters, and the details of that trust establishment depend on the issuance protocol and relationship between Attester and <del> Issuer. </del> <ins> Issuer.  This arrangement is shown in fig-overview. </ins> This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token

Discussion:
This is a little hard to process... An inbound PR I have proposes a change to the first diagram that might help here. A little work on this is probably necessary. !
A few things: When drawing arrows on lines, the line will connect with the line neatly if there is a connector or if there is an arrow adjacent to the line: This puts the arrow on the line, which renders a gap in the line. Avoid this: The bottom-left corner here is not curved, because the detection of corners needs three characters: the corner and a line either side of that, so... Not:
NAME can you say more about how it's hard to process? As we recently discussed, we're burdened by being too close to this work, so it's hard for me to see a substantial difference between the diagram in this issue and that which you proposed in the recently merged PR. Is it not clear who touches or sees each message? Part of the challenge in this particular diagram -- and any in which the attester is party to the protocol -- is that the attester may be inline or may not be! The architecture does not require the attester to be inline, it really only requires that the token request from a client be somehow blessed by the attester. I'll think about ways to better visualize this, but clarification about the source of confusion would be super helpful.
For me, the hardest part of these diagrams is that the start and end of the end of the arrows aren't really attached to anything in particular. You rely on horizontal alignment a fair bit (the arrow starts approximately under the label "Issuer", so it's probably a message from the issuer). In comparison, the diagram I provided had lines and boxes connecting them. This is probably a more illustrative example: ! Are the TokenRequest and TokenResponse labels on the lines? Where do these arrows start? Is the Client/Attester/Issuer box a single entity (obviously, no) given how the challenge arrows hit it. Which entities perform attestation? Then there are the formatting issues, some of which I will concede are specific to aasvg, see the above comment.
Thanks -- that's helpful. I think should resolve the confusion.
Change:
epoch's ratchet tree.  Each leaf in the AS Tree is associated with the same group member as the corresponding leaf in the ratchet tree. Nodes are also assigned an index according to their position in the <del> array representation of the tree (described in tree-math).  If V is a node in the AS Tree then IndexOf(V) denotes it's index while V.leftChild and V.rightChild denote the children of V (if they exist). </del> <ins> array representation of the tree (described in tree-math).  If N is a node index in the AS Tree then left(N) and right(N) denote the children of N (if they exist). </ins> Each node in the tree is assigned a secret.  The root's secret is simply the application_secret of that epoch.  (See key-schedule for the definition of application_secret.) The secret of any other node in the tree is derived from its parent's <del> secret using a call to Derive-Secret.  The context for the call is the (hash of the) Group state of the epoch and the index of the node whose secret is being derived. </del> <ins> secret using a call to Derive-App-Secret. </ins> <del> If V is a node in the ASTree then ASTreeContext[V] denotes an ASTreeContext variable with: gshash = Hash(GroupState_[n]) node_index = IndexOf(V) Moreover, the secrets of the children of V are defined to be: </del> <ins> If N is a node index in the ASTree then the secrets of the children of N are defined to be: </ins> Note that fixing concrete values for GroupState_[n] and application_secret completely defines all secrets in the AS Tree.

Discussion:
This PR implements a collection of comments on . It aims to achieve the goal stated by NAME of having every derivation have a different relationship, but with a simpler construction.
Ok, I think this is good enough : )
Change:
PSKs, primarily for the purposes of supporting TLS connections with fast open (0-RTT data). <ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs, primarily for the purposes of establishing TLS connections without requiring the overhead of provisioning and managing PKI certificates. </ins> Internet of Things (IoT) and devices with limited computational capabilities.  RFC7925 defines TLS and DTLS profiles for resource- constrained devices and suggests the use of PSK ciphersuites for <del> compliant devices. </del> <ins> compliant devices.  The Open Mobile Alliance Lightweight Machine to Machine Technical Specification LwM2M states that LwM2M servers MUST support the PSK mode of DTLS. </ins> Use of PSK ciphersuites are optional when securing RADIUS RFC2865 with TLS as specified in RFC6614.

Discussion:
Notes: Certificateless server-to-server communication is definitively used for OTT communications e.g. URL
Change:
example, a sender might populate these extensions with a randomly- sized amount of random data. <ins> GREASE values MUST NOT be sent in the following fields, because an unsupported value in one these fields (including a GREASE value), will cause the enclosing message to be rejected: "Proposal.proposal_type" "Credential.credential_type" "GroupContext.extensions" "GroupContextExtensions.extensions" </ins> A set of values reserved for GREASE have been registered in the various registries in iana-considerations.  This prevents conflict between GREASE and real future values.  The following values are

Discussion:
NAME and I have completed interop testing that covers all of the functionality in the spec. We found a couple of places where there were ambiguities in the spec that led to different implementation decisions, and in the process of resolving those, found a couple of errors / omissions in drarft-19. The current PSK proposal validation forbids with other than . The branch and reinit sections call for the creation of PSK proposals with types and . Given the text in the PSK section, these proposals would be invalid. This PR explicitly allows and in the specific context of those operations. (This is a little pro-forma, since the PSK proposals are only seen by the committer. But it seems good to allow the committer to have consistent PSK proposal validation logic.) The text says that Add, Remove, and ReInit proposals can be sent by external senders, but is silent about other proposal types. This PR explicitly indicates which proposal types may be originated by external senders, and adds an IANA registry column to track. GREASE values for proposal types, credential types, and extension types are defined for use in Capabilities, but nothing currently forbids their use elsewhere. This PR forbids their use in actual Proposal or Credential objects, and in GroupContext extensions. The field of the Proposal object was inconsistently referred to as both and . This PR changes it to be everywhere.
Merge when ready.
Change:
the signature computation comprises all of the fields except for the signature field. <del> KeyPackage objects MUST contain at least two extensions, one of type "supported_versions" and one of type "supported_ciphersuites".  These extensions allow MLS session establishment to be safe from downgrade attacks on these two parameters (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </del> <ins> KeyPackage objects MUST contain at least three extensions, one of type "supported_versions", one of type "supported_ciphersuites", and one of type "lifetime".  The "supported_versions" and "supported_ciphersuites" extensions allow MLS session establishment to be safe from downgrade attacks on these two parameters (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </ins> As the "KeyPackage" is a structure which is stored in the Ratchet Tree and updated depending on the evolution of this tree, each

Discussion:
I've put a bunch of little fixes in here. If you disagree with any of these changes, I can back them out or change them. maximal is defined but never used k-th leaf/leaf index is defined in two places; merge definitions change KeyPackage struct definition to reflect that ~2~ 3 extensions are required is also a required extension grammar fix add missing semicolon
One minor thing, otherwise LGTM
Change:
from the KDF for the group's ciphersuite, as well as the functions defined below: <ins> Where KDFLabel is specified as: </ins> The value "KDF.Nh" is the size of an output from "KDF.Extract", in bytes.  In the below diagram:

Discussion:
A few changes to make code blocks a little more consistent / usable / pretty: Fence every code block with exactly three tildes Mark each code block with a type ( / / / / ) Marking with generates slightly prettier pictures for the ladder diagrams in the introduction. Marking with makes it easy to programmatically extract the TLS syntax definitions in case we want to produce a syntax summary appendix like , or in case implementers want to quickly get a listing of all the structs they need. The only substantive changes I made here were: Removing the lines from the branch and re-inject PSK illustrations Splitting pseudocode from TLS syntax in a few cases.
Yeah, I specifically had the idea because I wanted to pull out the TLS syntax blocks to update my implementation :)
Nice idea! It would also allow someone to compile the document with syntax coloration for TLS formats and Python code.
Change:
followed: The port value is set to the port of the default ICE candidate for <del> this m= section; if this m= section is not being bundled into another m= section, the port value MUST be unique.  If no candidates have yet been gathered, and a 'null' port value is being used, as indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1., this port MUST still be unique. </del> <ins> this m= section, but given that no candidates have yet been gathered, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-mmusic-trickle-ice, Section 5.1. </ins> To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8. <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 gathered, the "c=" line must contain the "dummy" value "IN IP6 ::", as defined in I-D.ietf-mmusic-trickle-ice, Section 5.1. </ins> Each m= section MUST include the following attribute lines: An "a=mid" line, as specified in RFC5888, Section 4.  When

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2. <ins> The WTHEADERS frame has an additional flag, Unidirectional (0x40). When this flag is present, the stream starts in a half-closed state. The sending endpoint stream state is "half-closed (remote)" and the receiving endpoint state is "half-closed (local)". </ins> The WTHEADERS frame has one extra field, Connect Stream ID. WTHEADERS frames can be sent on a stream in the "idle", "open", or "half-closed (remote)" state, see stream-states.

Discussion:
As in the , We should document how we provide a unidirectional stream, likely by adding that as a parameter to the Connect stream.
Looking good! Few minor formatting nits, but nothing major.