jiebi/CodeConvo huggingface dataset:
Change:
entry point for requesting the links hosted by servers with known or discovered addresses RFC6690. <ins> 5.4. Assuming self-describing representation formats (i.e., human-readable with carefully chosen terms or processible by a formatting tool) and a client supporting the URI scheme used, a good rule of thumb for a good hypermedia-driven design is the following: A developer should only need an entry point URI to drive the application.  All further information how to navigate through the application (links) and how to construct more complex requests (forms) are published by the server(s).  There must be no need for additional, out-of-band information (e.g., API specification). For machines, a well-chosen set of information needs to be shared a priori to agree on machine-understandable semantics.  Agreeing on the exact semantics of terms for relation types and data elements will of course also help the developer. </ins> 6. Certain kinds of design problems are often recurring in variety of

Discussion:
I just gave this advice and it might be a good rule of thumb: Assuming human-readable representation formats (i.e., text-based not binary) and a client supporting the URI scheme used, a good rule of thumb for a good hypermedia-driven design is the following: A developer should only need an entry point URI to drive the application. All further information how to navigate through the application (links) and how to construct more complex requests (forms) are published by the server(s). There must be no need for additional, out-of-band information (e.g., API specification). For machines, a well-chosen set of information needs to be shared a priori to agree on machine-understandable semantics. (Agreeing on the exact semantics of terms for relation types and data elements will of course also help the developer.)
Yes, except that text-based doesn't mean human-readable (as exemplified by JSON -- in reality you need a formatting tool to look at any instances that aren't entirely trivial). More important is that the format is self-describing (and the tool you need to look at that not too obscure).
Yes, yes, all this is already in the assumptions to get a concise rule of thumb :) Next iteration: Assuming self-describing representation formats (i.e., human-readable with carefully chosen terms or processible by a formatting tool) and a client supporting the URI scheme used, a good rule of thumb for a good hypermedia-driven design is the following: A developer should only need an entry point URI to drive the application. All further information how to navigate through the application (links) and how to construct more complex requests (forms) are published by the server(s). There must be no need for additional, out-of-band information (e.g., API specification). For machines, a well-chosen set of information needs to be shared a priori to agree on machine-understandable semantics. (Agreeing on the exact semantics of terms for relation types and data elements will of course also help the developer.)
At least one little update :)Looks good. There's just a small problem: Nobody is doing it.
Change:
specification for the "flex" tool; this is intended to be close to "d", "p{L}", "w" in an ASCII subset.) <del> 4. The syntax of I-Regexp is defined by the ABNF specification in iregexp-abnf. This syntax is a subset of that of XSD2; the semantics of all the constructs allowed by this ABNF grammar are the same as those in XSD2. About a third of the complexity of this ABNF grammar comes from going into details on the Unicode IsCategory classes.  Additional complexity stems from the way hyphens can be used inside character classes to denote ranges; the grammar deliberately excludes questionable usage such as "/[a-z-A-Z]/". *Issue*: This is essentially XSD regexp without character class subtraction and multi-character escapes.  There might be further potential for simplification in IsBlock (leave out) and possibly in the rather large part for IsCategory as well.  The ABNF has been automatically generated and maybe could use some polishing. The ABNF has been verified against rfcs, but a wider corpus of regular expressions should be examined. 5. (TBD; these mappings need to be thoroughly verified.) 5.1. Any I-Regexp also is an XSD Regexp XSD2, so the mapping is an identity function. 5.2. Perform the following steps on an I-Regexp to obtain an ECMAScript regexp ECMA-262: Replace any dots (".") outside character classes (first alternative of "charClass" production) by "[^nr]". Envelope the result in "^" and "$". Note that where a regexp literal is required, this needs to enclose the actual regexp in "/". The performance can be increased by turning parenthesized regexps (production "atom") into "(?:...)" constructions. 5.3. Perform the same steps as in toESreg to obtain a valid regexp in PCRE PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: Envelope the result in "A" and "z". Again, the performance can be increased by turning parenthesized regexps (production "atom") into "(?:...)" constructions. 5.4. (Please submit the mapping needed for your favorite kind of regexp.) 6. </del> <ins> 7. </ins> This document makes no requests of IANA. <del> 7. </del> <ins> 8. </ins> TBD

Discussion:
This has had the motivation and background material moved into new sections after the syntax and semantics. The opening section have been RFC-i-fied a bit, with one MUST each for syntax and semantics.
Change:
The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other tracks in the same MediaStream, so that they can be added to the same <del> "LS" group when creating an offer or answer. addTrack attempts to minimize the number of transceivers as follows: If the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver that was created by the most recent call to setRemoteDescription() and does not have a local track. Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </del> <ins> "LS" group when creating an offer or answer, thus allowing these tracks to be synchronized when played out, as described in RFC5888, Section 7.  addTrack attempts to minimize the number of transceivers as follows: If the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver that was created by the most recent call to setRemoteDescription() and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </ins> 4.1.3.

Discussion:
NAME PTAL at the reformulation I added.
"LS" (lipsync) is first used at 4.1.2, with no context for what it is. Please add a reference.
OK
Change:
Unlike TLS over TCP, QUIC applications which want to send data do not send it through TLS "application_data" records.  Rather, they send it <del> as QUIC STREAM frames which are then carried in QUIC packets. </del> <ins> as QUIC STREAM frames or other frame types which are then carried in QUIC packets. </ins> 4.

Discussion:
Mention that application data could be conveyed in other frame types than STREAM frames. (E.g. the proposed DATAGRAM draft sends application data in DATAGRAM frames.)
This was correct at the time, because only STREAM carried application semantics, but that's too constraining, even now. Thanks.
Change:
client needs to respond with information to complete the challenges. To do this, the client updates the authorization object received from the server by filling in any required information in the elements of <del> the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </del> <ins> the "challenges" object.  (This is also the stage where the client should perform any actions required by the challenge.) </ins> The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type,

Discussion:
Follow-up to , catches a few more references I initially missed.
I think 'field name' makes more sense... but I'm not really wed to either.
Change:
then added to the table.  It is an error if the encoder attempts to add an entry that is larger than the dynamic table capacity; the decoder MUST treat this as a connection error of type <del> "HTTP_QPACK_ENCODER_STREAM_ERROR". </del> <ins> QPACK_ENCODER_STREAM_ERROR. </ins> A new entry can reference an entry in the dynamic table that will be evicted when adding this new entry into the dynamic table.

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
implementations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension. <ins> Implementations which have the same policy in both cases MAY omit the "signature_algorithms_cert" extension. </ins> The "extension_data" field of these extension contains a SignatureSchemeList value:

Discussion:
In your answer to my question on list you say: and chain validation. I don't see that covered by this PR. Shouldn't this be explicit?
then the "signature_algorithms" extension also applies to signatures appearing in certificates. is unaffected by this change
As NAME says, there is already text that implies that you need not send "signature_algorithms" cert, so I don't think new text is really needed here.
That sentence says nothing about under what circumstances it is ok to omit "signaturealgorithmscert". It only implies that you may not always get it. I think it would not hurt to be more explicit.
Change:
done on a per-codec basis (e.g., if the offerer somehow offered support for CN but set "usedtx=0" for Opus, setting VoiceActivityDetection to true would result in an answer with CN <del> codecs and "usedtx=0"). </del> <ins> codecs and "usedtx=0").  The impact of this rule is that an answerer will not try to use silence suppression with any endpoint that does not offer it, making silence suppression support bilateral even with non-JSEP endpoints. </ins> 5.4.

Discussion:
LGTM
I am going to land this and then make a followup PR for S 5.9.
You'll also need to update S 5.9 to ensure CN is only enabled when support is bilateral: For each specified "CN" media format, enable DTX for all supported media formats with the same clockrate, as described in [RFC3389], Section 5, except for formats that have their own internal DTX mechanisms. DTX for such formats (e.g., Opus) is controlled via fmtp parameters, as discussed in Section 5.2.3.2.
Change:
The keys used for packet protection are computed from the TLS secrets using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label function described in Section 7.1 of TLS13 is used, using the hash <del> function from the negotiated cipher suite.  Note that labels, which are described using strings, are encoded as bytes using ASCII ASCII without quotes or any trailing NUL byte.  Other versions of TLS MUST provide a similar function in order to be used with QUIC. </del> <ins> function from the negotiated cipher suite.  All uses of HKDF-Expand- Label in QUIC use a zero-length Context. Note that labels, which are described using strings, are encoded as bytes using ASCII ASCII without quotes or any trailing NUL byte. Other versions of TLS MUST provide a similar function in order to be used with QUIC. </ins> The current encryption level secret and the label "quic key" are input to the KDF to produce the AEAD key; the label "quic iv" is used

Discussion:
This was a pretty serious omission, even if it was obvious enough that no one ever noticed when implementing it.
NAME said:
The Context thing should be addressed by . The 4 bits should be "Unused" to match the transport spec. I'll fix that.
NAME said:
Oh, so many things to unpack from a short comment... Yes, Context should be explicitly empty. I'll create a PR for this and the other, below. The TLS transcript is integrated into the derivation of the keys that we use, so we don't need to include it again. As an aside, EAP-TLS1.3 use of 0x0D in the exporter is counter to the intended use of the field. They already have all the fixed key separation necessary through the use of the exporter label. The field is intended to capture variable, contextual information such as identities or other things that are not already folded into the handshake. I agree that using a different span of the handshake transcript for key derivation would be massively disruptive, that is why I would oppose doing that. As with Context, so too with Length, though that requires a little more text to address. That's in the PR too. Note: I had to decide between NMAX and NMIN and chose N_MAX. Though the values are the same for all of the AEADs we use, that isn't guaranteed. I'm sure that an AEAD with variable-length nonce could manage, but no sense in being imprecise. I want nothing to do with Derive-Secret. That's too far into TLS internals.
I think that the separation that we have now is good and that we do not need to change the design. Regarding IV length, as stated in the PR review comment, we are using TLS cipher-suites. Therefore I think we should be using what is defined in TLS 1.3 (i.e. ) rather than specifying a different rule.
Change:
efficiently encrypt messages to subsets of the group.  Each epoch has a distinct ratchet tree. <del> Each member of the group maintains a view of these two facets of the </del> <ins> A _secret tree_ derived from the key schedule that represents shared secrets used by the members of the group to provide confidentiality and forward secrecy for MLS messages.  Each epoch has a distinct secret tree. Each member of the group maintains a view of these facets of the </ins> group's state.  MLS messages are used to initialize these views and keep them in sync as the group transitions between epochs.

Discussion:
In the Protocol Overview, Figure 1 shows a ratchet tree, commitsecret, epochsecret, encryptionsecret, and a secret tree, while the text discusses the epochsecret and encryption_secret. Then the next section, Cryptographic State and Evolution states that "There are two types of cryptographic state at the core of MLS:" a key schedule, and a ratchet tree. The Secret Tree isn't mentioned there. Then we have a Key Schedule section which then includes a Secret Tree sub-section. Readers are left wondering what the relationship is between the the Key Schedule and Secret Tree.
Change:
4. ACME allows a client to request certificate management actions using <del> a set of JSON messages carried over HTTPS.  In some ways, ACME </del> <ins> a set of JSON messages carried over HTTPS.  In many ways, ACME </ins> functions much like a traditional CA, in which a user creates an <del> account, adds identifiers to that account (proving control of the domains), and requests certificate issuance for those domains while logged in to the account. In ACME, the account is represented by an account key pair.  The "add a domain" function is accomplished by authorizing the key pair for a given domain.  Certificate issuance and revocation are authorized by a signature with the key pair. </del> <ins> account, requests a certificate, and proves control of the domains in that certificate in order for the CA to sign the requested certificate. </ins> <del> The first phase of ACME is for the client to register with the ACME server.  The client generates an asymmetric key pair and associates this key pair with a set of contact information by signing the contact information.  The server acknowledges the registration by replying with a account object echoing the client's input. </del> <ins> The first phase of ACME is for the client to request an account with the ACME server.  The client generates an asymmetric key pair and requests a new account, optionally providing contact information, agreeing to terms of service, and/or associating the account with an existing account in another system.  The creation request is signed with the generated private key to prove that the client controls it. </ins> <del> Once the client is registered, there are three major steps it needs to take to get a certificate: </del> <ins> Once an account is registered, there are three major steps the client needs to take to get a certificate: </ins> Submit an order for a certificate to be issued

Discussion:
Several places talked about account key pairs as being the primary notion of an account, while the account is now primary and has a public key associated with it. Updated to clarify that. Clarified that the account request can contain more than just contact information. Fixed the order of operations in protocol summary to reflect new-order flow.
Change:
Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a <del> problem on wireless networks.  See RFC6716, Section 2.1.7 for complete details. </del> <ins> problem on wireless networks.  See RFC6716, Section 2.1.7, and OpusFEC for more details. </ins> For AMR/AMR-WB, packets can contain copies or lower-quality encodings of multiple prior audio frames.  See RFC4867, Section 3.7.1 for

Discussion:
I believe this came from a WG mailing list post (possibly my own), rather than an external document that could be linked to. Suggestions? Unfortunately, that was the best RFC reference I could find.
Change:
4.2.2. Upon receipt of a QUIC packet, the load balancer extracts the <del> selected bits of the SCID and expresses them as an unsigned integer of that length.  The load balancer then divides the result by the chosen divisor.  The modulus of this operation maps to the modulus for the destination server. </del> <ins> selected bits of the Server CID and expresses them as an unsigned integer of that length.  The load balancer then divides the result by the chosen divisor.  The modulus of this operation maps to the modulus for the destination server. </ins> <del> Note that any SCID that contains a server's modulus, plus an </del> <ins> Note that any Server CID that contains a server's modulus, plus an </ins> arbitrary integer multiple of the divisor, in the routing bits is routable to that server regardless of the contents of the non-routing bits.  Outside observers that do not know the divisor or the routing <del> bits will therefore have difficulty identifying that two SCIDs route to the same server. </del> <ins> bits will therefore have difficulty identifying that two Server CIDs route to the same server. </ins> Note also that not all Connection IDs are necessarily routable, as the computed modulus may not match one assigned to any server.  These

Discussion:
Server CID will collide with Source CID.
This is often used to mean Source Connection ID in other contexts. A collision here is likely to cause confusion.
Recommended name? SCCID?
I think it might just be best to call it the "Server CID" any other abbreviated term will get confused IMO.
"Server CID" doesn't seem to fit well with "Stream Cipher Connection ID"
So SCID didn't mean "Server Connection ID"? There is definitely confusion here. I'd just recommend not abbreviating anything more than CID.
I guess this proves MT's point. "STream Cipher Connection ID" (just like PCID, OCID, BCID)
Looking again, the document never uses any acronym for 'stream cipher connection ID', so there's no issue there. This is just about 'S' meaning "source" or "server".
Change:
the value of the extension in the GroupContext, according to the semantics of the specific extension. <del> A client joining a group MUST populate the GroupContext extensions with exactly the contents of the extensions field in the Welcome message.  If any extension is unrecognized (i.e., not contained in the corresponding KeyPackage), then the client MUST reject the Welcome message and not join the group. </del> <ins> If any extension in a GroupInfo message is unrecognized (i.e., not contained in the corresponding KeyPackage), then the client MUST reject the Welcome message and not join the group. The extensions populated into a GroupContext object are drawn from those in the GroupInfo object, according to the definitions of those extensions. </ins> Note that the latter two requirements mean that all MLS extensions are mandatory, in the sense that an extension in use by the group

Discussion:
A couple of shortcomings to note on this PR: The joiner can't compute their private keys because they're not told where they are in the tree or how big the tree is. The former should be added to and the latter to . This approach assumes that the joiner gets the tree OOB before processing the Welcome, otherwise they can't verify the signature on the Welcome. (Since Welcome presumes they get the credential for the signer from the tree.) We could avoid the latter problem by including a credential for the signer and a "membership proof" comprising the hashes needed to tie that leaf to the tree hash in the Welcome. That could allow participants to remain "passive" (without a full tree, just their private keys) for longer, especially if such a proof could be provided on Commit as well. This might be a good candidate for an extension, though.
Discussion at the 2020-07-14 interim indicated that we should go ahead with this strategy, and just note the requirement that you have to get the tree before you process the Welcome.
I remember we discussed this in the past, but I don't think we ever spec'ed this out fully: Right now the whole tree is part of (which in turn is part of ). This can grow quite big in large groups (~17MB with 100k members with the MTI). The practical limitations are: The TLS representation of the tree is hard to parse efficiently (no skipping and no a priori information of how many nodes are in the tree) Out-of-band transmission (like server assist) is not possible Large messages like that are hard to handle on mobile devices, when they have to be downloaded in the background We should introduce an indirection, like a commit hash of the tree.
Change:
the reports in sub-batches of 10.  Each sub-batch takes two round- trips to process. <del> In order to allow the helpers to retain minimal state, the helper can attach a state parameter to its response, with the leader returning the state value in the next request, thus offloading the state to the leader.  This state value MUST be cryptographically protected as described in agg-init. </del> [OPEN ISSUE: Should there be an indication of whether a given aggregate request is a continuation of a previous sub-batch?]

Discussion:
This is a follow-up to , removing a few dangling references to the helper state blob.
Change:
the payload of an ICMP message to associate the message with a corresponding transport connection (see Section 4.6.1 of DPLPMTUD). ICMP message validation MUST include matching IP addresses and UDP <del> ports BCP145 and, when possible, connection IDs to an active QUIC </del> <ins> ports RFC8085 and, when possible, connection IDs to an active QUIC </ins> session.  The endpoint SHOULD ignore all ICMP messages that fail validation.

Discussion:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.