jiebi/CodeConvo huggingface dataset:
Change:
above. If the m= section is not bundled into another m= section (i.e., it <del> is either not bundled or it is associated with the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= section is bundled into another m= section, it MUST NOT have any ICE credentials. </del> <ins> is either not bundled or it possesses the sender's BUNDLE-tag) each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option (sec.icerestart was specified.  If the m= section is bundled into another m= section, it MUST NOT contain any ICE credentials. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering

Discussion:
First cut. Need to update the examples.
Overall LG, a handful of comments
LGTM
lgtm and merged. Will do a new PR to handle minor tweaks
BUNDLE draft 27 (URL) indicates that ICE attributes and candidates in re-offers (and with max-bundle, I'm guessing) should only be in the "m=" line associated with the offerer BUNDLE-tag. In other words, the candidates and ICE parameters are not duplicated unnecessarily across m= sections. We should update JSEP to reflect this.
Change:
A PreSharedKey proposal is invalid if any of the following is true: <del> The "psktype" in the PreSharedKeyID struct is set to "resumption" and the "usage" is "reinit" or "branch". </del> <ins> The PreSharedKey proposal is not being processed as part of a reinitialization of the group (see reinitialization), and the PreSharedKeyID has "psktype" set to "resumption" and "usage" set to "reinit". The PreSharedKey proposal is not being processed as part of a subgroup branching operation (see subgroup-branching), and the PreSharedKeyID has "psktype" set to "resumption" and "usage" set to "branch". </ins> The "psk_nonce" is not of length "KDF.Nh".

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:
Packets protected with Initial secrets (initial-secrets) are not authenticated, meaning that an attacker could spoof packets with the intent to disrupt a connection.  To limit these attacks, Initial <del> packet protection keys can be discarded more aggressively than other </del> <ins> packet protection keys are discarded more aggressively than other </ins> keys. The successful use of Handshake packets indicates that no more

Discussion:
Too fast! Thanks.
This will require rewrapping, which I can do if you prefer.
Change:
WT_DATA_BLOCKED frames contain the following field: <del> Maximum Data: A variable-length integer indicating the session-level limit at which blocking occurred. </del> <ins> A variable-length integer indicating the session-level limit at which blocking occurred. </ins> 5.9.

Discussion:
Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).
Change:
Additional information: <del> Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .pem Macintosh file type code(s): n/a </del> Person & email address to contact for further information: See Authors' Addresses section.

Discussion:
For pem-certificate-chain, the "Addition information" section was getting jumbled all onto one line by the Markdown to HTML generator. The table for Fields in Account Objects was jumbled. In the template for some registries, a field was called "Client configurable" in the next but "Configurable" in the table. Changed to always say "Configurable."
Change:
4.2.1. Transport Properties are referred to by property names.  These names <del> are lower-case strings whereby words are separated by hyphens.  These names serve two purposes: </del> <ins> are lower-case alphanumeric strings in which words may be separated by hyphens.  These names serve two purposes: </ins> <del> Allow different components of a TAPS implementation to pass </del> <ins> Allowing different components of a TAPS implementation to pass </ins> Transport Properties, e.g., between a language frontend and a policy manager, or as a representation of properties retrieved from a file or other storage. <del> Make code of different TAPS implementations look similar. </del> <ins> Making code of different TAPS implementations look similar. </ins> Transport Property Names are hierarchically organized in the form [<Namespace>.]<PropertyName>. <del> The Namespace part MUST be empty for well-known, generic </del> <ins> The Namespace component MUST be empty for well-known, generic </ins> properties, i.e., for properties that are not specific to a protocol and are defined in an RFC.

Discussion:
Clarify how the IANA protocol numbers registry keywords (largely upper-case) textually relate to Transport Property Names. Refine some of the surrounding text.
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 RFC 2119 RFC2119. </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> The following terms are used:

Discussion:
RFC 8174 updates RFC 2119 so the boilerplate words have changed slightly according to s2 of RFC 8174. Just trying to save us another GENART comment.
Change:
An HTTP response with a 2xx status code (RFC7231 Section 6.3) indicates a valid DNS response to the query made in the HTTP request. A valid DNS response includes both success and failure responses. <ins> For example, a DNS failure response such as SERVFAIL or NXDOMAIN will contain a successful HTTP 2xx status code even though there was a failure at the DNS layer.  Responses with non-successful HTTP status codes do not contain DNS answers to the question in the corresponding request.  Some of these non-successful HTTPS responses (such as redirects or authentication failures) could allow clients to make new requests to satisfy the original question. </ins> Different response media types will provide more or less information from a DNS response.  For example, one response type might include

Discussion:
intended
largely a restating of mailing list thread: A question on the mix of DNS and HTTP semantics
keep pr but reopen the issue to add a little more text
PRs during meetings iz hArd
Change:
This structure incorporates everything in an MLSPlaintext up to the confirmation field in the transcript that is included in that <del> confirmation field (via the GroupState).  The confirmation and </del> <ins> confirmation field (via the GroupContext).  The confirmation and </ins> signature fields are then included in the transcript for the next operation.  The intermediate hash enables implementations to in corporate a plaintext into the transcript without having to store the

Discussion:
Race condition between and
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 2 issues have been closed and 0 issues are still open. :heart: , by :heart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 9 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there were no stargazers. - - 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:
The createAnswer method generates a blob of SDP that contains an SDP answer per RFC3264 with the supported configuration for the session that is compatible with the parameters supplied in the most recent <del> call to setRemoteDescription, which MUST have been called prior to calling createAnswer.  Like createOffer, the returned blob contains descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options negotiated for this session, and any </del> <ins> call to setRemoteDescription; setRemoteDescription MUST have been called prior to calling createAnswer.  Like createOffer, the returned blob contains descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options negotiated for this session, and any </ins> candidates that have been gathered by the ICE agent.  An options parameter may be supplied to provide additional control over the generated answer.

Discussion:
This includes Removing my postal address. Mozilla closed that office. small editorial changes Removing bogus whitespace.
NAME PTAL
NAME I think I've got your changes and we are ready to land?
LGTM
Change:
The browser MUST indicate any windows which are currently being shared in some unambiguous way.  Windows which are not visible <del> MUST not be shared even if the application is being shared.  If </del> <ins> MUST NOT be shared even if the application is being shared.  If </ins> the screen is being shared, then that MUST be indicated. Clients MAY permit the formation of data channels without any direct

Discussion:
There were two instances of "MUST not" that need to be "MUST NOT"
Address I-D nits complaints.
Change:
and then reinjected as a "handshake_hash" message, as described in the-transcript-hash. <del> 4.2.10.2. </del> <ins> 4.2.10.3. </ins> Clients are permitted to "stream" 0-RTT data until they receive the server's Finished, only then sending the EndOfEarlyData message.  In

Discussion:
…s , , .
NAME if you want to propose some revised text, I will TAL.
From Nikos's comment:
This is relating to . I will try to resolve both issues.
It is hard to understand the current text of Section 4.2.9.3 (Replay Properties). NAME explained me that a server should check: The server can tell: serverrecvtime == now serversendtime == one parameter in the ticket clientsendtime - clientrecvtime == ticketage == obfuscatedticketage + ticketage_add If this understanding is correct, I would suggest to add more explanation to the section.
Yes, that's correct. PRs welcome
I made a tweak to avoid referring to the "base value", in , though more changes may still be helpful.
Change:
Attester, then a Client may use either of these trusted Attesters to issue and redeem tokens for origin.example.  However, origin.example neither explicitly specifies nor learns the <del> Attesters or their attestation formats used for token issuance. </del> <ins> Attesters or their specific attestation procedures used for token issuance. </ins> Redemption context.  Challenges can be bound to a given redemption context, which influences a client's ability to pre-fetch and

Discussion:
From Section 3.2.1: This is a pretty wild equivalence. I stumbled badly on this one. It's very much like saying "in this context a verb is sometimes referred to as a noun". Is the goal here to say that "there is a attestation process by which the Attester determines whether a Client meets the requirements for issuance; if successful, the Attester captures this information using an attestation format" ? That seems to be the case, but that's not what this says.
I think we might just drop the equivalence to avoid confusion, but in the interest of transparency, here's where it came from. Consider the two following types of attestation procedures: Attestation based on , where the client and attester use this mechanism to prove that the client's device is valid. Attestation based on , perhaps where the signature is computed in some client enclave, where the client authenticates its token request with such a ring signature. In (1), attestation is some procedure that takes place between client and attester, whereas in (2) attestation is sort of non-interactive mechanism for producing an attestation format or proof of sorts. Since we don't specify the details of attestation, the text was written in a way to be maximally accommodating to these types of things. In any case, I think it's probably fine to just treat attestation as a procedure_, be it interactive or non-interactive or whatever, and that procedure has certain properties associated with it. I'll propose text.
Change:
multiple integer DH groups.  The shares for each ClientKeyShareOffer MUST by generated independently.  Clients MUST NOT offer multiple ClientKeyShareOffers for the same parameters.  It is explicitly <del> permitted to send an empty client_key_share extension as this is used to elicit the server's parameters if the client has no useful information.  [TODO: Recommendation about what the client offers. Presumably which integer DH groups and which curves.] </del> <ins> permitted to send an empty "client_key_share" extension as this is used to elicit the server's parameters if the client has no useful information. [[TODO: Recommendation about what the client offers.  Presumably which integer DH groups and which curves.]] </ins> 6.3.2.3.1.

Discussion:
Modified extension requirements based on recent list discussion. It's a little verbose with repeated boilerplate, but it's clear no matter which section you read now. I've also moved the relevant requirements up top to a consistent place for each extension's section. The level of strictness here is now: If attempting to negotiate and the mandatory extension isn't available: MUST error If just detecting an invalid combination, but not actively negotiating: MAY error SNI is clearly listed as MUST support, servers MAY require, and SHOULD error if required The "unsupportedextension" alert is reworded more generally and put in as the consequence for violating the pre-existing "MUST NOT" send the client-only extensions from a server requirements. Also added some more, namely the fact that "clientkey_share" is clearly an error to be sent from a server.
NAME & NAME Please take a look when you get a chance. Are we all on the same page with this language? Anything that needs tweaking to focus on the above better? Edited to add: Also, do I need to cut out SNI again, or is this wording ok? It's not requiring it to be sent, just noting it must be supported, which was agreed to on list a while ago, and noting the existing case that servers MAY require it with a way to indicate it using the new error alert.
NAME New commit pushed here with changes for your comments: "invalid" -> "prohibited" Text is now: "Servers MUST NOT negotiate use of cipher suites unless the client supplies a supported . If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert." So, trying to find a viable cipher suite is preferred and the error is only required when there's nothing else to do. Edited to note: The latter doesn't contradict the mandatory error on negotiation without the needed extension, as the server simply has the (unlikely) chance of negotiating something completely different instead. The MAY error is still included later in the changeset, as discussed, so clients are still expected to always do this correctly or risk the server throwing an error.
NAME Ok, repushed with one-word change to clarify to "at least one group for each ephemeral key exchange algorithm". This excludes PSK, but is still fine for (EC)DHE when used with it. Seems like the simplest fix.
Change:
authentication that both limits the probability of forgery by the same amount and does not expose implementations to the risk of denial of service; see ccm-short.  Therefore, TLS_AES_128_CCM_8_SHA256 MUST <del> NOT used in DTLS without additional safeguards against forgery. </del> <ins> NOT be used in DTLS without additional safeguards against forgery. </ins> Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on an understanding of any additional forgery protections that are used.

Discussion:
[ section 4.4 ] "respectively" -> "respectively." Could a DTLS implementation packetize to a min-MTU for an IP version and avoid all pMTU issues? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications. [ section 4.5.3 ] "MUST NOT used" -> "MUST NOT be used" [ section 5.8.4 ] "NOT have send" -> "NOT send", I think [ section 6 ] "which are needed to encrypt to decrypt"?
and avoid all pMTU issues? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications. I'm reluctant to recommend this, given that we know one can run into situations where there is more overhead due to tunnels, etc.
Change:
An indexed header field representation identifies an entry in the static table, or an entry in the dynamic table with an absolute index <del> less than the Base. </del> <ins> less than the value of the Base. </ins> This representation starts with the '1' 1-bit pattern, followed by the 'T' bit indicating whether the reference is into the static or

Discussion:
This change has been suggested by afrind at URL on the basis that the Base is a count, and comparing an index to a count feels awkward.
Change:
m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <ins> If the m= section is not bundled into another m= section and RTCP multiplexing is not active, an "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate. If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial answer section above. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather-overview), an "a=candidate" line MUST be

Discussion:
LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin
Change:
"certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential". <ins> 1.1. (*) indicates changes to the wire protocol. draft-02 Change DelegationUsage extension to be NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. (*) Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate. </ins> 2. A delegated credential is a digitally signed data structure with two <del> semantic fields: a validity interval, and a public key (with its associated algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the TLS server operator.  The secret key used to sign a credential is presumed to be one whose corresponding public key is contained in an X.509 certificate that associates one or more names to the credential. </del> <ins> semantic fields: a validity interval and a public key (along with its associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the TLS server operator.  The secret key used to sign a credential corresponds to the public key of the X.509 end-entity certificate. </ins> A TLS handshake that uses credentials differs from a normal handshake in a few important ways:

Discussion:
Based on This adds a change log with changes from draft-01. It drops the proposed "must-use-DC" semantics from the X.509 extension. There doesn't seem to be a clean way to do this, and the complexity it adds seems to outweigh any potential benefit. The changes are as follows: Change DelegationUsage extension type to NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. () Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate.
Not sure why CI failed ... It's building fine on my end.
Back to you NAME :)
looks great to me
Change:
the special meaning described in RFC2119. The terms "push message", "push service", "push subscription", <del> "application server", and "user agent" are used as defined in I- D.ietf-webpush-protocol. </del> <ins> "application server", and "user agent" are used as defined in RFC8030. </ins> 2.

Discussion:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.