jiebi/CodeConvo huggingface dataset:
Change:
9.7.6. <del> This registry lists the ways that ACME servers can offer to validate control of an identifier.  The "Identifier Type" field in the template must be contained in the Label column of the ACME Identifier Types registry. </del> <ins> This registry lists identifiers for the ways that CAs can validate control of identifiers.  Each method's entry must specify whether it corresponds to an ACME challenge type.  The "Identifier Type" field must be contained in the Label column of the ACME Identifier Types registry. </ins> Template: <del> Label: The value to be put in the "type" field of challenge objects using this validation mechanism </del> <ins> Label: The identifier for this validation method </ins> <del> Identifier Type: The type of identifier that this mechanism applies to </del> <ins> Identifier Type: The type of identifier that this method applies to </ins> <del> Reference: Where the challenge type is defined </del> <ins> ACME: "Y" if the validation method corresponds to an ACME challenge type; "N" otherwise. Reference: Where the validation method is defined </ins> Initial Contents <ins> When evaluating a request for an assignment in this registry, the designated expert should ensure that the method being registered has a clear, interoperable definition and does not overlap with existing validation methods.  That is, it should not be possible for a client and server to follow take the same set of actions to fulfill two different validation mechanisms. Validation methods do not have to be compatible with ACME in order to be registered.  For example, a CA might wish to register a validation method in order to support its use with the ACME extensions to CAA I- D.ietf-acme-caa. </ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]]

Discussion:
It is useful in some contexts (e.g., ) to have identifiers for non-ACME methods that CAs use to validate control of an identifier. This PR updates the ACME Challenge Types registry to instead address Validation Methods more generally, with a column that indicates whether the method is an ACME method.
Okay, I see your point. Fine.
Change:
If HTTPS is used, JSON or CBOR payloads may be supported.  If JSON payloads are used, the semantics of Sections 4.1.3 and 4.1.4 of the OAuth 2.0 specification MUST be followed (with additions as described <del> below).  If CBOR payload is supported, the semantics described in this section MUST be followed. </del> <ins> below).  If the CBOR payload formaat is supported, the semantics described in this section MUST be followed. </ins> For the AS to be able to issue a token, the client MUST be authenticated and present a valid grant for the scopes requested.

Discussion:
This terminology decision was made in early days of OAuth = long time ago. Done. Done. Changed. I added a note that this confidentiality protection of the access token happens on top of the protection offered by the underlying communication security protocol. Text added. >-- Section 5 -- Text changed. >-- Section 5.1.1 -- >Could the word "unprotected" be better defined in "received on an unprotected channel" ? E.g., is it only about TLS ? Else, I like the implicit lack of trust. Text changed to "unsecured channel" >-- Section 5.1.2 -- I assume you mean "Section 5.3". Text added. >-- Section 5.5 -- >In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or "e.g." ? I cannot find this text in the document. >-- Section 5.6 -- OK OK. >-- Section 5.6.4.1 -- >In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I failed to spot them in RFC 6749. Done. >-- Section 5.7.2 -- >It is a little unclear to me which profile must be used as 'profile' is optionnial? Should a default or any profile be used ? I cannot find this text. >-- Section 5.8.1 -- >Suggest to use the BCP14 "SHOULD" in the text "The default name of this endpoint in an url-path is '/authz-info'" Changed. >-- Section 10.2 -- >Is RFC 7049 really an informative reference as CBOR appears as the default encoding ? Changed to a normative reference and updated reference. All nits below have been addressed.
Comments addressed in this PR: URL
Merged
Change:
stateless reset size. Endpoints MUST discard packets that are too small to be valid QUIC <del> packets.  With the set of AEAD functions defined in QUIC-TLS, packets that are smaller than 21 bytes are never valid. </del> <ins> packets.  To give an example, with the set of AEAD functions defined in QUIC-TLS, short header packets that are smaller than 21 bytes are never valid. </ins> Endpoints MUST send stateless reset packets formatted as a packet with a short header.  However, endpoints MUST treat any packet ending

Discussion:
Minimum packet size varies between the packet types (and other things like the length of CID being used). Therefore, the sentence is merely providing an example, and should be stated as such. .
Currently section 10.3 of the transport doc says: However, Version Negotiation packets are not guaranteed to be larger than 21 bytes. For example, a VN packet with an 0-byte destination connection ID, 8 byte source connection ID and single version would be 19 bytes. If a client receives such a packet, must it be dropped? This text suggests it must. But it's not clear to mean (or the slack channel) that this interpretation is expected. Of course, a server could work around this issue by appending a sufficient number of GREASE'd versions to make the packet large enough. But I'm not sure if that is mandatory?
The second sentence merely points out that QUIC packets that use AEAD can never be smaller than 21 bytes. VN packets do not use AEAD, hence that 21 byte limit does not apply. Of course, endpoints can do their own maths to figure out the minimal size of VN packets that they might receive. Just my two cents. We might want to clarify the italic part ("that use AEAD") in the specification.
I agree with NAME that the spec isn't technically wrong, but I find it unclear. It wouldn't surprise me if someone were to read this and add to their packet ingestion code. I think all we need here is an editorial clarification such as
Note: 21 is the correct number, as requires endpoints to expand the payload size to at least 4 + len(AEAD tag), so that we can always have full-sized entropy for header protection.
Thanks Kazuho, this is great. What I like about this is that it also implies the possibility of a higher minimum. For instance, the limit on long headers is higher (28 for Initial, 27 for 0-RTT and handshake if I'm right, but you can also add the minimum connection ID length for receiving to that).
Change:
A UDP Multicast Receive Connection is ready once the system has received traffic for the appropriate group and port. <del> UDP Multicast Receive Connections generate an InitiateError if Initiate is called. Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network. </del> <ins> UDP Multicast Receive Connections generate an InitiateError indicating that joining a multicast group failed if Initiate is called. </ins> LISTEN.UDP.  Calling "Listen" for UDP Multicast Receive binds a local port, prepares it to receive inbound UDP datagrams from

Discussion:
(More out of curiosity, with no expectation that this would find its way into the text unless you think I've hit a bug): In UDP Multicast Receive, which kind of ICMP notifications can come in there that would constitute a ConnectionError -- given that this transport does not send (and would thus usually not trigger any)?
Section 10.4 for multicast receive mentions ICMP errors. You could have errors on initiate for joining a multicast group, etc, but it likely doesn't make sense to have ICMP errors mentioned here.
Suggest we can close this issue.
LGTMSeems like we do not loose anything by removing this. The change WFM.
Change:
The tokens are protected using AES128-GCM as follows: <del> The Key Sequence is the 8 bit identifier to retrieve the token key </del> <ins> The Key Sequence is the 7 bit identifier to retrieve the token key </ins> and IV. The AEAD IV, is a 96 bit data which produced by implementer's

Discussion:
Takes the RSCID out of the token body because the server can catch mismatches with the DCID if it's used as associated data.
I have read URL but still don't understand why we need to include it again in token. I'd thought that that server or retry service can read it from the Initial packet (invariant long header packet). What happen if they are different? Which one server should take to initiate the connection?
I recommend Section 7.3 of RFC 9000 to understand this: "The values provided by a peer for these transport parameters MUST match the values that an endpoint used in the Destination and Source Connection ID fields of Initial packets that it sent (and received, for servers). Endpoints MUST validate that received transport parameters match received connection ID values." The connection IDs in Retry and Initial packets are not effectively authenticated unless they are included in transport parameters, which are included in key computation. If the server doesn't have a trustworthy record of the CID it picked (this token), it has no way of confirming that the Retry's SCID wasn't modified in flight.
yeah, I get that server needs to verify SCID in Retry packet. I still do not get why we need to include Retry SCID again in the token.
How would it verify the SCID was unchanged if it wasn't in the token?
I think it'd be authenticated by including in the associated data, i.e
Hmm, this is a clever proposal. I'll reopen to reconsider properly.
Trying to wrap my head around this. The server wants to verify that the RSCID is correct, so the current solution is to copy that in the token. If the client messes up, the server compares the value in the token to the value sent by the client. Yes, putting that in the pseudo header will mostly work. If the client does not use the specified RSCID, the token will just not decode. But there are two potential issues: 1) Debugging is harder. For example, there will not be any way to differentiate between wrong RSCID and wrong IP 2) If the token came as "NEW TOKEN", there is no RSCID specified. There will need to be a special case for constructing the pseudo header, but that means exposing the difference between Retry Token and New Token in clear text.

In any case, we would need additional text for the New Token case.
Christian, good point on (2). The NSS Token already distinguishes the types in cleartext, so perhaps that's not such a big deal. But yes, we'd need to take a bit from the key sequence to indicate the token type.
I filed , please take a look.
Change:
a "subscription" URI enables the receipt of messages or deletion of the subscription.  Acquiring a "push" URI permits the sending of push messages.  Logging could also reveal relationships between different <del> subscription-related URIs for the same user agent. </del> <ins> subscription-related URIs for the same user agent.  Encrypted message contents are not revealed to the push service. </ins> Limitations on log retention and strong access control mechanisms can ensure that URIs are not learned by unauthorized entities.

Discussion:
I realized that I hadn't done due diligence in adding the message URL. This should address that (I have hooks in here for acknowledgment too).
Change:
Similarly, HTTP/3 can transport field values that are not valid. While most values that can be encoded will not alter field parsing, <del> carriage return (CR, ASCII 0x0d), line feed (LF, ASCII 0x0a), and the zero character (NUL, ASCII 0x00) might be exploited by an attacker if they are translated verbatim.  Any request or response that contains a character not permitted in a field value MUST be treated as malformed (malformed).  Valid characters are defined by the "field- content" ABNF rule in HTTP. </del> <ins> carriage return (ASCII 0x0d), line feed (ASCII 0x0a), and the null character (ASCII 0x00) might be exploited by an attacker if they are translated verbatim.  Any request or response that contains a character not permitted in a field value MUST be treated as malformed (malformed).  Valid characters are defined by the "field-content" ABNF rule in HTTP. </ins> 10.4.

Discussion:
The RFC Editor asks:
Along the way, there are two equivalent statements that need to be deduplicated that this change touches: I would suggest collapsing these two into the first statement, but using OPTIONS as an example and keeping the reference into http-core. Or perhaps that should be a question -- is there a difference between asterisk-form and OPTIONS-without-path?
Resolved in .
Change:
Note(1): Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined <del> differently, only specifying the symmetric ciphers, and cannot it be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suites </del> <ins> differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suites </ins> cannot be used with TLS 1.3. Note(2): Cipher suites marked as "Yes" are those allocated via

Discussion:
This PR and
ship it
From the draft: Remove one "are" from "are are reserved".
Remove the "it" from "cannot it" in the text below:
From the Introduction section: As far as I can see the above ought to be:
Change:
(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-16 Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better backwards compatibility (*) </ins> draft-15 New negotiation syntax as discussed in Berlin (*)

Discussion:
PR changed enum values which would need updating by any experimental implementations that were actually using them. Even if this doesn't come up in practice, it should be listed in the changelog.
Change:
behalf of the client.  This may be useful, for example, when the client lacks the capability to make the request itself or to service the response from a cache in order to reduce response <del> time, network bandwidth and energy consumption. </del> <ins> time, network bandwidth, and energy consumption. </ins> A reverse proxy that provides an interface to a non-RESTful system such as legacy systems or alternative technologies such as Bluetooth ATT/GATT.  See also "Reverse Proxy". <del> A component embedded in a representation that identifies a resource for future hypermedia interactions, such as a link or a form.  If the client engages in an interaction with the identified resource, the result may be a change to resource state and/or client state. </del> <ins> A component, such as a link or a form, embedded in a representation that identifies a resource for future hypermedia interactions.  If the client engages in an interaction with the identified resource, the result may be a change to resource state and/or client state. </ins> A method where multiple identical requests with that method lead <del> to the same visible resource state as a single such request.  For example, the PUT method replaces the state of a resource with a new state; replacing the state multiple times with the same new state still results in the same state for the resource.  However, the response from the server can be different when the same idempotent method is used multiple times.  For example when DELETE is used twice on an existing resource, the first request would remove the association and return success acknowledgement whereas the second request would likely result in error response due to non-existing resource. </del> <ins> to the same visible resource state as a single such request. </ins> A hypermedia control that enables a client to navigate between resources and thereby change the client state.

Discussion:
Note about client role and reference to architecture section for details.
+1 (if the newline in the definitions () still does render correctly...
How do you like your newlines cooked?
The definitions seem to render correctly. I'll merge this.
Change:
of information that Issuer's may learn about Clients otherwise. Since this metadata may be useful for practical deployments of Privacy Pass, Issuers must balance this against the reduction in <del> Client privacy.  In general, Issuers should permit no more than 32 bits of metadata, as this can uniquely identify each possible user. We discuss this more in parametrization. </del> <ins> Client privacy.  In general, Issuers should bound the metadata permitted so as to not allow it to uniquely identify each possible user. </ins> 5.2.

Discussion:
After quickly skimming the parameterization section, it became clear that we already discuss these things in various consideration sections throughout the document, so this was just redundant. Moreover, it's very use-case and deployment specific that once had value in the joint deployment model, so it doesn't seem like particularly helpful now that we've generalized things a bit. Removing and avoiding confusion seems like the best path forward.
I'll take this one to the list before merging.
The privacy calculations should be updated to take into account metadata more explicitly, and take into account the cost of the number of redemptions, rather than the global issuer count. If used in a multiple disjoint architecture ecosystem, then the math should also be taken in terms of a specific 'context' rather than treating the whole PrivacyPass ecosystem as a single global system (allowing for more nuanced requirements/limitations on issuer counts).
On reflection, we may be better off deleting the text entirely and making sure the justification for the parameterization is adequately covered in the security and privacy considerations elsewhere in the document.
Change:
cryptographic agility on the document signing ecosystem and vice versa. <del> There is no issue if the vendor defined OIDs are used in a PKI (or a trust program) governed by the vendor.  However, if the OID is used outside of the vendor governance, the usage can easily become out of control (e.g. - When the end user encounters vendor defined OIDs, they might want to ask that vendor about use of the certificate, however, the vendor may not know about the particular use. - If the issuance of the cert is not under the control of the OID owner, there is no way for the OID owner to know what the impact will be if any change is made to the OID in question, and it would restrict vendor's choice of OID management. etc.). </del> <ins> There is no issue if the vendor-defined KeyPurposeIds are used in a PKI (or a trust program) governed by the vendor.  However, if the KeyPurposeId is used outside of vendor governance, the usage can easily become out of control (e.g. - When the end user encounters vendor-defined KeyPurposeIds, they might want to ask that vendor about use of the certificate, however, the vendor may not know about the particular use. - If the issuance of the cert is not under the control of the KeyPurposeId owner, there is no way for the KeyPurposeId owner to know what the impact will be if any change is made to the KeyPurposeId in question, and it would restrict vendor's choice of OID management.  etc.). </ins> <del> Therefore, it is not favorable to use a vendor defined EKU for signing a document that is not governed by the vendor. </del> <ins> Therefore, it is not favorable to use a vendor-defined KeyPurposeId for signing a document that is not governed by the vendor. </ins> <del> This document defines a general Document Signing extended key purpose identifier. </del> <ins> This document defines a extended key purpose identifier for Document Signing. </ins> 2.

Discussion:
Try to used KeyPurposeId (or key purpose, key purpose identifier, etc.), to express more accurately. Add some changes, related with restrictive expression of document signing KeyPurposeId, etc.
on the section 4, it seems better to change some of "EKU" to "KeyPurposeId" or "EKU values" to highlight following. excluded EKUs procedures checks, whether EKU values contain some OID(KeyPurpiseId), or absence of EKU extension. permitted EKU procedures check, whether EKU values contain some OID(KeyPurposeId).
Current expression on "Excluded EKUs procedure " and "Permitted EKU procedure" seems unclear about whether that procedure prohibits or allows, existence of certain key purpose identifier in the extended key usage value (partial match), OR certain set of key purpose identifier is on key usage value(exact match). my intension was the former. I will review, and will fix that expression if it were unclear. In addition, I will add "restrictions set is derived and implemented from (or configured with) the policy to which the implementation conforms." to clarify policy handling by RP or implementer.
Change:
as sending a Stateless Reset. An endpoint cannot determine the Source Connection ID from a packet <del> with a short header, therefore it cannot set the Destination </del> <ins> with a short header; therefore, it cannot set the Destination </ins> Connection ID in the Stateless Reset.  The Destination Connection ID will therefore differ from the value used in previous packets.  A random Destination Connection ID makes the connection ID appear to be

Discussion:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.
Change:
The "Connection Priority" Connection Property operates on Connections in a Connection Group using the same approach as in msg-priority: when allocating available network capacity among Connections in a <del> Connection Group, sends on Connections with lower Priority values will be prioritized over sends on Connections with higher Priority values.  Capacity will be shared among these Connections according to the Connection Group Transmission Scheduler property (conn- scheduler).  See priority-in-taps for more. </del> <ins> Connection Group, sends on Connections with higher Priority values will be prioritized over sends on Connections that have lower Priority values.  Capacity will be shared among these Connections according to the Connection Group Transmission Scheduler property (conn-scheduler).  See priority-in-taps for more. </ins> 8.

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:
path, the transport system will try the path first, ignoring the preference. <del> Selection, and Connection Properties, as well as defaults for Message </del> <ins> Selection and Connection Properties, as well as defaults for Message </ins> Properties, can be added to a Preconnection to configure the <del> selection process, and to further configure the eventually selected </del> <ins> selection process and to further configure the eventually selected </ins> protocol stack(s).  They are collected into a TransportProperties object to be passed into a Preconnection object:

Discussion:
I guess we could actually remove all commas in this sentence but previously there were definitely too many...