jiebi/CodeConvo huggingface dataset:
Change:
The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running <del> on a home router.  "not_before" and "not_after" fields represent the validity period of the published ESNI keys.  Clients MUST NOT use ESNI keys that was covered by an invalid checksum or beyond the published period.  Servers SHOULD set the Resource Record TTL small enough so that the record gets discarded by the cache before the ESNI keys reach the end of their validity period. </del> <ins> on a home router. "not_before" and "not_after" fields represent the validity period of the published ESNI keys.  Clients MUST NOT use ESNI keys that was covered by an invalid checksum or beyond the published period. Servers SHOULD set the Resource Record TTL small enough so that the record gets discarded by the cache before the ESNI keys reach the end of their validity period.  Note that servers will need to retain the decryption key for some time after "not_after" to deal with clock skew, internal caches, and the like. </ins> Client MAY cache the ESNIKeys for a particular domain based on the TTL of the Resource Record, but SHOULD NOT cache it based on the not_after value, to allow servers to rotate the keys often and <del> improve forward secrecy (due to clock skew on the client, it may not be possible for the server to use a very short key lifetime).  Note that servers will need to retain the decryption key for some time after not_after to deal with clock skew, internal caches, and the like. </del> <ins> improve forward secrecy. </ins> Note that the length of this structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035.

Discussion:
I'm not sure this is much better. I would changes the "Note that servers..." sentence to something like:
See URL
Change:
These examples show multiple policies being returned: <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del> <ins> This field can be sent in a trailer section. </ins> 3.3.

Discussion:
According to URL there is no need to specify that information.
This text appears in relation to Item fields. By their nature Items can only occur on one field line (the proper terminology, btw), so this requirement is extraneous, and should be removed.
... and it's also on RateLimit-Policy, even though that is a List field.
Change:
This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and <del> other elements.  Some examples use a single trailing backslash '' to </del> <ins> other elements.  Some examples use a single trailing backslash "" to </ins> indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.

Discussion:
Apostrophes were accidentally used instead of backticks to render the backslash as code.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ffdb4ee91464d098f38e69f9bd5e6936a5a009a8 Inspect the deploy log: Browse the preview:
Change:
When designing a RESTful system, the state of the distributed application must be assigned to the different components.  Here, it <del> is important to distinguish between "session state" and "resource </del> <ins> is important to distinguish between "client state" and "resource </ins> state". <del> Session state encompasses the control flow and the interactions </del> <ins> Client state encompasses the control flow and the interactions </ins> between the components (see sec-terms).  Following the statelessness <del> constraint, the session state must be kept only on clients.  On the </del> <ins> constraint, the client state must be kept only on clients.  On the </ins> one hand, this makes requests a bit more verbose since every request must contain all the information necessary to process it.  On the other hand, this makes servers efficient, since they do not have to

Discussion:
Addressing issue
Thanks Ari :) I will do a final pass and merge.
Originally, application state defined the state kept on the client, that is, what Web page is currently rendered and which pages were visited before. This does not make sense anymore when resource state is more than static Web pages, but parameters, physical state, etc. "Application state" logically would mean the state of the overall IoT application (state of the client and resoource state).
Related comment by Mike Amundsen:
I would add a comment in the definition, that this is called "Application State" in Fielding's thesis, but has some ambiguity in mordern (IoT) applications, where resource state is very dynamic and reflects part of the state in which the overall application is.
Change:
generates the Evidence about the layout of the Composite Device, while sub-Attesters generate Evidence about their respective modules. <del> An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  The combination of roles can be arbitrary.  For example, in this Composite Device scenario, the entity inside the lead Attester can also take on the role of a Verifier, and the outside entity of Verifier can take on the role of a Relying Party.  After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and appraisal policies (obtained the same way as any other Verifier) in the verification process to generate Attestation Results.  The inside Verifier then conveys the Attestation Results of other Attesters, whether in the same conveyance protocol as the Evidence or not, to the outside Verifier. </del> In this situation, the trust model described in trustmodel is also suitable for this inside Verifier. <ins> 3.6. An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  Multiple entities can cooperate to implement a single RATS role as well.  The combination of roles and entities can be arbitrary.  For example, in the Composite Device scenario, the entity inside the lead Attester can also take on the role of a Verifier, and the outer entity of Verifier can take on the role of a Relying Party.  After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and appraisal policies (obtained the same way as any other Verifier) in the verification process to generate Attestation Results.  The inside Verifier then conveys the Attestation Results of other Attesters to the outside Verifier, whether in the same conveyance protocol as the Evidence or not. </ins> 4. This document uses the following terms.

Discussion:
2nd to last para. in composite device section should be be given its own section heading - ## Entity
The second to last paragraph in Composite Device section is not describing composite devices. Instead it describes role-entity semantics. It should be given its own section heading e.g. "Entities" and the last paragraph / sentence should be moved up (into the composite device section).
Change:
10.3. <del> The account recovery processes described in account-recovery allow authorization to be transferred from one account key to another, in case the former account key pair's private key is lost.  ACME needs to prevent these processes from being exploited by an attacker to hijack the authorizations attached to one key and assign them to a key of the attacker's choosing. Recovery takes place in two steps: 1.  Provisioning recovery information (contact or recovery key) 2.  Using recovery information to recover an account The provisioning process needs to ensure that only the account key holder ends up with information that is useful for recovery.  The recovery process needs to assure that only the (now former) account key holder can successfully execute recovery, i.e., that this entity is the only one that can choose the new account key that receives the capabilities held by the account being recovered. Account recovery uses both the ACME channel and the contact channel. The provisioning process is only visible to an ACME MitM, and even then, the MitM can only observe the contact information provided.  If the ACME attacker does not also have access to the contact channel, there is no risk. The security of the recovery process is entirely dependent on the security of the contact channel.  The details of this will depend on the specific out-of-band technique used by the server.  For example: If the server requires a user to click a link in a message sent to a contact address, then the contact channel will need to ensure that the message is only available to the legitimate owner of the contact address.  Otherwise, a passive attacker could see the link and click it first, or an active attacker could redirect the message. If the server requires a user to respond to a message sent to a contact address containing a secret value, then the contact channel will need to ensure that an attacker cannot observe the secret value and spoof a message from the contact address. In practice, many contact channels that can be used to reach many clients do not provide strong assurances of the types noted above. In designing and deploying recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact-based recovery schemes that achieve an appropriate level of risk using those contact channels. 10.4. </del> As a protocol run over HTTPS, standard considerations for TCP-based and HTTP-based DoS mitigation also apply to ACME.

Discussion:
This PR is a re-do of . It only removes recovery; it does not add the "account-mgmt" metadata item.
LGTM
We removed recovery in . If we refactor roll-over as proposed in , however, recovery can be done much more simply, at least if you assume the client is provisioned with a MAC key (possibly out of band).
Agreed at IETF 96 that we will not specify recovery. Instead, we will add some guidance for CAs as to how to handle loss of account keys.
Change:
The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. <del> 8.2. </del> <ins> 9.2. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection.

Discussion:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos
Change:
PRIORITY frame sent on a control stream with the Prioritized Element Type set to "11" MUST be treated as a connection error of type HTTP_MALFORMED_FRAME.  A PRIORITY frame with Empty bits not set to <del> zero MUST be treated as a connection error of type </del> <ins> zero MAY be treated as a connection error of type </ins> HTTP_MALFORMED_FRAME. When a PRIORITY frame claims to reference a request, the associated

Discussion:
in the PRIORITY frame
I agree, this doesn't seem to mesh with the discussion on the issue. If nothing else, it introduces the inconsistency NAME pointed out, but the gist of the issue seems to be that a receiver MAY check that it's zero.
NAME Are you in favor of changing MUST to MAY, should I discard the PR, or have I misunderstood your comment completely?
MUST => MAY
PR kicked up a bit more controversy than expected, so I'm opening an issue. Currently he Empty bits it the PRIORITY frame MUST be zero and MUST be ignored by the receiver. In most other areas, we're killing connections for this kind of violation. Then again, HTTP/3 is a different protocol from QUIC. What do people think?
Closing the connection SGTM.
I can live with must be zero and connection error if not.
Which means drop requirement to ignore them.
I'd keep the requirement to ignore them on receipt -- why require more unnecessary checking?
That works, but then state that their value is completely meaningless and should not be interpreted as anything
NAME you want to add verbiage in addition to this?
Looking back to HTTP/2, it had this to say about in-frame PADDING in DATA frames. Padding octets MUST be set to zero when sending. A receiver is not obligated to verify padding but MAY treat non-zero padding as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. URL
That is probably OK here as well. Though the need is less acute for a 4 bit field. Padding in DATA can be arbitrarily large. Either way, the hope would be that at least a few implementations check and enforce.
I don't see how this agrees with the field requirement that empty bits are ignored Empty: A four-bit field which MUST be zero when sent and MUST be ignored on receipt.
Change:
the external init secret as described in external-initialization. The sender type for the MLSAuthenticatedContent encapsulating the <del> External Commit MUST be "new_member_commit " </del> <ins> External Commit MUST be "new_member_commit". </ins> External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's

Discussion:
This will guarantee that all group members agree on the ciphersuite used. It gives more meaning to statements like "Each MLS session uses a single ciphersuite". Also, it prevents the following attack: the adversary (a malicious insider) invites someone and convinces them that the group uses a ciphersuite with say a signature scheme that is weaker but still compatible with the one actually used. Now the new member uses a weaker scheme and the adversary can impersonate them.
Interim 2022-06-02: Agreement that more binding is better
Change:
allocated to the senders and setting maximum media bit-rate boundaries. <del> TODO: any others? </del> As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.

Discussion:
I think there may still be more work to do here, but we can track in the existing bug () rather than a TODO.
Raised by Magnus.
URL
R-10 (a=ssrc) should probably be removed or adjusted to reflect the fact that JSEP won't generate these lines.
I'm starting on this one
We need to look at the PR started on this and see if this is something we want to do or if we should go the direction of just calling out the non obvious implementation requirements here.
This seems fixed. Closing it
Cullen to inspect document and ensure all relevant SDP RFCs are cited in the generating/parsing offer/answer sections (using full list in )
Is this resolved by ?
Yes. Closing.
Change:
If the "VoiceActivityDetection" option is specified, with a value of "true", the offer MUST indicate support for silence suppression in the audio it receives by including comfort noise ("CN") codecs for <del> each supported clock rate, as specified in RFC3389, Section 5.1. This option allows for significant bandwidth reductions with codecs such as G.711. </del> <ins> each offered audio codec, as specified in RFC3389, Section 5.1, except for codecs that have their own internal silence suppression support.  For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is desired.  For example, when using the Opus codec, the "usedtx=1" parameter would be specified in the offer.  This option allows the endpoint to significantly reduce the amount of audio bandwidth it receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. </ins> 5.2.3.4.

Discussion:
Late breaking, so if we decide to hold this until after Toronto, no worries
LGTM
Close enough for me. Merge it.
Change:
The body is the DNS on-the-wire format defined in RFC1035. When using the GET method, the body MUST be encoded with base64url <del> RFC4648. Padding characters for base64url MUST NOT be included. </del> <ins> RFC4648 and then placed as a name value pair in the query portion of the URI with name "dns".  Padding characters for base64url MUST NOT be included. </ins> When using the POST method, the body MUST NOT be encoded.

Discussion:
partially addresses martin is right - the naming of this query parameter was just asking for pain. new coat of paint is in order.
:+1:
I've seen an implementation report that confused base64 and base64url; they noted that the examples didn't include one where the distinction was important
NAME yes, there is also the bit about not having the sign paddings that caught me at first. During the DOH proxy implementation, I missed the padding part. I have it implemented in URL and I think it is correct :) Would an example implementation in a language be worth adding to the examples? It may be more straightforward to read than examples. URL documentation says: This may be worth highlighting as what base64url is too.
This is complicated by the fact that some people want the encoding of responses to GET to be media-type-specific.
I think you mean GET request body parameters (not responses - which are always in bodies and not encoded)
Yes, I meant body parameters.
Please stop calling the parameter . It's really confusing. (I just read this and thought to myself "GET doesn't have a body").
note that the current encoded url in the github copy is wrong as it wasn't updated when the dns id changed to 0. I'll fix that as part of making a base 64 example.
Change:
entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. <del> Its first argument is a string that is matched against the iregexp contained in the string that is the second argument.  The result is "true" if the string matches the iregexp and "false" otherwise. </del> <ins> Its first argument is an optional string that is matched against the iregexp contained in the string that is the second argument.  The result is "true" if the string matches the iregexp and "false" otherwise. </ins> The result is "Nothing" if the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf-

Discussion:
Fixes URL
NAME I pushed cb1cf124ab to clarify optional arguments.
NAME raised this in a PR review.
I think the answer is "yes" because that allows the function to be used on a Singular Path rather than on just a literal.
Yes. I would expect any function that can take a path must allow any value.
That should be enough to remove this double-take.
Change:
Otherwise, ignore the candidate. <del> Multicast DNS resolution might end up retrieving both an IPv4 and IPv6 address.  In that case, the IPv6 address may be used preferably to the IPv4 address. </del> <ins> An ICE agent may use a hostname resolver that transparently supports both Multicast and Unicast DNS.  In this case the resolution of a ".local" name may happen through Unicast DNS, see RFC6762 section 3. An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others.  The ICE agent SHOULD, if available, use the first IPv6 address resolved, otherwise the first IPv4 address. 2.2.1. A peer-reflexive remote candidate could be learned and constructed from the source transport address of the STUN Binding request as an ICE connectivity check.  The peer-reflexive candidate could share the same address as a remote host ICE candidate that will be signaled or has been signaled, received and is in the process of name resolution. In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer- reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </ins> <del> 4. </del> <ins> 3. </ins> <del> 4.1. </del> <ins> 3.1. </ins> When there is no user consent, the following filtering should be done to prevent private IP address leakage:

Discussion:
Attacks by message flooding and name registration blocking are detailed.
This PR is doing some renaming. Maybe it should be done in a separate commit PR. Also, the mention of a mdns name per browsing context might conflict with another PR.
LGTM with change to make limit browser-wide.
LGTM
Change:
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier <del> draft-ietf-tls-rfc4492bis-14 </del> <ins> draft-ietf-tls-rfc4492bis-15 </ins> Abstract

Discussion:
Use initialism consistently in the Introduction Mention EdDSA in addition to ECDSA as a signature scheme
lgtm
Change:
We define a new X.509 extension, DelegationUsage, to be used in the certificate when the certificate permits the usage of delegated <del> credentials. </del> <ins> credentials.  What follows is the ASN.1 X680 for the DelegationUsage certificate extension. </ins> The extension MUST be marked non-critical.  (See Section 4.2 of RFC5280.)  The client MUST NOT accept a delegated credential unless

Discussion:
I suspect at some point somebody would have asked for an ASN.1 module. I know not everybody uses an ASN.1 compiler, but some do. I also know Russ Housley was going through an making for all of the RFCs that include ASN.1. He also double checked that the ASN.1 module compiles (if you put a dummy OID in for the TBD it will compile). An OID is need from the PKIX arc, but Russ is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections.
"An OID is need from the PKIX arc, but Russ is the IANA DE there so it is not like we do not know who we need to ask - hence the updated IANA considerations sections." Are you thinking of getting a different OID for the DCs, does the cf OID not work?
Sean is talking about the Module Identifier. The CF OID inside the module is fine.
The CF OID for the extension works just fine - in fact I should have left the sentence in the PR explaining that. We need an OID for the ASN.1 module (TBD). Technically, I guess we do not need an OID if CF has an ASN.1 module already. But, I suspect there wasn't an ASN.1 module. Make sense?
NAME do you know if CF has an ASN.1 module already?
since noone seems to have any objections, merging away.
Not having an ASN.1 module for the certificate extension has bit us in the a** before. I will make one and add it in as an appendix.
Change:
approximately matches the bandwidth requirement estimates from several video providers is given in MSOD: <del> Height and width are in pixels, and frame rate is in frames per second.  The actual bitrate required for a specific video will also depend on the codec used, fidelity desired and some other characteristics of the video itself, such as the amount and frequency of high-detail motion, which may influence the compressability of the content, but this equation provides a rough estimate. </del> <ins> Height and width are in pixels, frame rate is in frames per second, and the motion factor is a value that ranges from 20 for a low-motion talking heads video to 7 for sports, and content with a lot of screen changes. The motion factor captures the variability in bitrate due to the amount and frequency of high-detail motion, which generally influences the compressability of the content. The exact bitrate required for a particular video also depends on a number of specifics about the codec used and how the codec-specific tuning parameters are matched to the content, but this equation provides a rough estimate that approximates the usual bitrate characteristics using the most common codecs and settings for production traffic. </ins> Here are a few common resolutions used for video content, with their <del> typical per-user bandwidth requirements according to this formula: </del> <ins> typical and peak per-user bandwidth requirements for 60 frames per second (FPS): </ins> 2.1.2.

Discussion:
This is my attempt at the changes we discussed in URL to include both the high-end and the typical bitrate needs.
Changes look good to me.