jiebi/CodeConvo huggingface dataset:
Change:
against an intermediary changing the request URL to another ACME URL. As noted in request-authentication above, all ACME request objects <del> carry a "url" parameter in their protected header.  This header parameter encodes the URL to which the client is directing the </del> <ins> carry a "url" header parameter in their protected header.  This header parameter encodes the URL to which the client is directing the </ins> request.  On receiving such an object in an HTTP request, the server <del> MUST compare the "url" parameter to the request URL.  If the two do not match, then the server MUST reject the request as unauthorized. </del> <ins> MUST compare the "url" header parameter to the request URL.  If the two do not match, then the server MUST reject the request as unauthorized. </ins> Except for the directory resource, all ACME resources are addressed with URLs provided to the client by the server.  For these resources, <del> the client MUST set the "url" field to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" fields. </del> <ins> the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" header parameter. </ins> 6.3.1. The "url" header parameter specifies the URL RFC3986 to which this <del> JWS object is directed.  The "url" parameter MUST be carried in the protected header of the JWS.  The value of the "url" header MUST be a string representing the URL. </del> <ins> JWS object is directed.  The "url" header parameter MUST be carried in the protected header of the JWS.  The value of the "url" header parameter MUST be a string representing the URL. </ins> 6.4.

Discussion:
This pull request includes changes to: Consistently use "header parameter" when referring to JWS header parameters. Insert a missing right curly bracket in a section reference. Use "server-initiated" instead of "administratively initiated" for clarity. Use parallel sentence structure for clarity/readability.
Change:
RDAO: Clarify that it is an option for RAs and not other ND messages. <del> Examples: Use example URIs rather than unclear reg names (unless it's RFC6690 examples, which were kept for continuity) </del> <ins> Examples: Use example URIs rather than unclear reg names (unless it's RFC6690 examples, which were kept for continuity) The LwM2M example was reduced from an outdated explanation of the complete LwM2M model to a summary of how RD is used in there, with a reference to the current specification. </ins> changes from -24 to -25

Discussion:
This is a series of commits removing cruft in the examples as discussed in URL Diverging from the discussion outcome, more than a single line was kept of 10.2, as the historical note left in , by analogy, means that we should mention that application's choice of a fixed path as well. Some commits may be added still as I'm going through the list.
I'm merging this in to ensure it interacts well with the example updates (where the resource types were replaced with actual example values); any follow-ups will go to a separate PR.
Change:
Altogether, the Issuer's directory could look like: <del> Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer- directory; see wkuri-reg for the registration information for this well-known URI. </del> <ins> Issuer directory resources have the media type "application/token- issuer-directory" and are located at the well-known location /.well- known/token-issuer-directory; see wkuri-reg for the registration information for this well-known URI. </ins> 4.

Discussion:
The caption for is: "'xxx' Well-Known URI", which is probably wrong.
This is a bit of a hard one to decide for me, but I think that you want to define a media type for the JSON directory. I know that in most cases the content will be served from a .well-known location, but that isn't always.
What would be the benefit of a media type here if the content will always be JSON? That is, I don't see how a media type would influence consumers of the resource.
So that you can make it clear that it is this specific JSON, as opposed to some other JSON.
The table appears without the text referring to it, even with an "as follows". It might be better to reference it directly.
Change:
only packets being sent, but this document does not describe a mechanism for doing so. <ins> The congestion controller is per path, so packets sent on other paths do not alter the current path's congestion controller, as described in Section 9.4 of QUIC-TRANSPORT. </ins> The algorithm in this document specifies and uses the controller's congestion window in bytes.

Discussion:
From the transport draft's connection migration section.
Section 9.4 in Transport(URL) does a nice job of explaining the RTT and congestion control implications of migration, but given one might reasonably expect some or all of that text to exist in recovery, I think it makes sense to reference it more. In particular, "Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path." is a useful sentence.
Change:
applications can choose to make it available to new members in order to allow External Commits. <del> External Commits work like regular Commits, with a few differences: </del> <ins> In principle, External Commits work like regular Commits.  However, their content has to meet a specific set of requirements: </ins> External Commits MUST contain a "path" field (and is therefore a "full" Commit).  The joiner is added at the leftmost free leaf

Discussion:
The current description of external commits still leaves room for the committer to include various other proposals such as arbitrary proposals that are not Update or Remove proposals (e.g., Adds, RequiredCapability, PSK, etc.). I think we should narrow that down to a specific set of proposals (i.e. an allow list style) to keep the implementation and general protocol complexity low for external commits, both for creation and processing. The way I see it, the new joiner can always issue a follow-up commit for other proposals, but I might be missing important use-cases, so I'd be grateful for feedback on this.
I agree with the intent here. Looking through the list of proposal types, the only other one that seems like it might be useful is PSK -- I could see it being useful to prove that you have a PSK when joining from the outside. If we can add that as an option (probably in parallel to Remove), this seems good to go to me.
Would an External Commit adding yourself contain an Add or an Update Proposal?
It used to contain an proposal, but since that's pretty much redundant with the the commiter has to include, it got optimized away. So an external commit should be handled as if it contained an Add proposal, where the KeyPackage in the Add is instead in the .
Comment by NAME Why RECOMMENDED and not MUST ?
Change:
should have its track removed.  The sender's track is cleared, and the sender stops sending.  Future calls to createOffer will mark the m= section associated with the sender as recvonly (if <del> transceiver.currentDirection is sendrecv) or as inactive (if transceiver.currentDirection is sendonly). </del> <ins> transceiver.direction is sendrecv) or as inactive (if transceiver.direction is sendonly). </ins> 4.1.4.

Discussion:
is meant to represent "direction in effect", whereas represents "direction the application wants to negotiate". So, the direction that both inspects and modifies should be ; its purpose is to change the application's desired direction for a transceiver, regardless of the current state of negotiation. Also clarifying that also reflects the direction negotiated in a provisional answer, which was the intent (I believe) but wasn't explicitly stated. This is consistent with it being the direction "in effect", since applying a provisional answer allows the endpoint to start sending/receiving media.
NAME do you want to look at this? I believe this is straightforward.
Section 4.1.3, removeTrack, states: This should say "transceiver.direction". Using "currentDirection" doesn't work because it may be null, and it also may result in un-intuitive behavior, where ends up not having any effect and results in a "sendrecv" or "sendonly" direction being negotiated.
Want to make a PR?
Change:
Property that an application specified as Preferred may not actually be present in the chosen protocol stack because none of the currently available transport protocols had this <del> feature.  Selection Properties of a Connection can only be queried. </del> <ins> feature. </ins> Protocol Properties of the protocol stack in use (see protocol- <del> props below).  These can be queried and set.  Certain specific Procotol Properties may be read-only, on a protocol- and property-specific basis. </del> <ins> props). </ins> For Connections that are Established, properties of the path(s) in use.  These properties can be derived from the local provisioning domain RFC7556, measurements by the Protocol Stack, or other <del> sources.  They can only be queried. </del> <ins> sources. Slightly different from "querying", a SoftError Event can also occur, informing the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the underlying protocol stack supports access to soft errors; however, even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. </ins> 10.

Discussion:
Rather than saying "this can only be queried" everywhere, I split this into setting and querying now, and I also moved SoftErrors in there. It's not precisely "querying" for a Property, but it's the closest match - better than "Connection Termination", I think (this is where SoftErrors were before).
NAME what about "Connection Maintenance: Setting Properties and Obtaining Information" ?
Maintenance sounds a bit strange to me, "Managing Connections: Setting Properties and Obtaining Information" ?
I like it (and I agree about "maintenance" being slightly strange)
Managing sounds good to me too.
Ack, done
lgtm, thanks!
Change:
The designated expert RFC8126 only ensures that the specification is publicly available. <del> Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implementation's completeness and some implementers blindly implement cipher supported.  Therefore, IANA [SHALL add/has </del> <ins> Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as checklist against which to measure an implementation's completeness and some implementers blindly implement groups supported.  Therefore, IANA [SHALL add/has </ins> added] the following warning to the registry: Cryptographic algorithms and parameters will be broken or weakened

Discussion:
NAME let me know what you think.
I.e., if you actually deploy on the Internet with these experimental code points, and you run into someone using the same code point, you're going to have a bad day. For widespread experiments, we should really be using temporary reservations of some kind instead.
NAME NAME How about we add the following note everywhere we added private use: NOTE: : As specified in {{RFC5226}}, assignments made in the Private Use space "are not generally useful for broad interoperability." It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
LGTM.
Addressed by .
Change:
4. <del> ECH uses draft-05 of HPKE for public key encryption I-D.irtf-cfrg- </del> <ins> ECH uses draft-06 of HPKE for public key encryption I-D.irtf-cfrg- </ins> hpke.  The ECH configuration is defined by the following "ECHConfig" structure.

Discussion:
ESNI seems to rely on TLS 1.3 KeyShareEntry which makes it incompatible with TLS 1.2. That's unfortunate with that "The protocol designed in this document is quite straightforward." The gist of ESNI comes down to "encryptedservername extension, which contains the true extension encrypted under the provider’s public key." That seems pretty generic and backwards compatible.
To prevent cut-and-paste attacks, you need to bind ESNI to the CH. That means we’d need 1.2 clients to send a key share in the CH to use when deriving encryption keying material, and that’s not currently done.
Since TLS 1.2 sends the server certificate in plaintext it seems like ESNI wouldn't be particularly useful there anyway, no?
Indeed. I guess someone could argue about wildcard certificates or when multiple names are present but the names are usually related so I agree there’s no significant benefit from encrypting the SNI.
Change:
1. The Privacy Pass protocol as described in draft-davidson-pp-protocol <del> can be integrated with a number of different settings, from server to server communication to browsing the internet. </del> <ins> can be integrated with a number of different settings, from Server to Server communication to browsing the internet. </ins> In this document, we will provide an API to use for integrating Privacy Pass with an HTTP framework.  Providing the format of HTTP

Discussion:
cc NAME for review. Mainly just removing the interfaces that were previously present and using the API functions from the protocol directly. I've also changed some of the wording around the key registry, and replaced client -> Client and server -> Server. Let me know if there is anything that you think I've missed.
We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.
I've removed the interfaces from the architecture doc () and used the protocol API directly in the HTTP doc ()
Change:
might be destroyed sooner, as soon as handshake keys are available (see Section 4.10 of QUIC-TLS). <del> 6.5. </del> <ins> 6.6. </ins> The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet.

Discussion:
Moves the "Retry and Version Negotiation" out of the "Crypto Retransmission Timeout" section in preparation for a redo of
Change:
actually accepts the call, the application can plug in the real MediaStreamTrack and create a new "sendrecv" offer to update the previous offer/answer pair and start bidirectional media flow.  While <del> this could also be done with a "sendonly" pranswer, followed by a </del> <ins> this could also be done with a "sendonly" pranswer followed by a </ins> "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.

Discussion:
used suggestion 2, deleted comments, issue 12
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right
Change:
padding is to be done to prevent or discourage such analysis.  (For example, the text strings could be defined as 'YES' and 'NO '.) <ins> When either COSE_Encrypt and COSE_Mac is used and more than two parties share the key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key. Countersignatures of COSE_Encrypt and COSE_Mac with short authentication tags do not provide the security properties associated with the same algorithm used in COSE_Sign.  To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits.  A countersignature of a COSE_Mac with AES-MAC 256/128 provides at most 64 bits of integrity protection.  Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at most 32 bits bits of integrity protection. </ins> 7. This section records the status of known implementations of the

Discussion:
When either COSEEncrypt and COSEMac is used and more than two parties share the key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key. Countersignatures of COSEEncrypt and COSEMac with short authentication tags do not provide the security properties associated with the same algorithm used in COSESign. To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits. A countersignature of a COSEMac with AES-MAC 256/128 provides at most 64 bits of integrity protection. Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at most 32 bits bits of integrity protection.
Change:
the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. <del> The received record counter for a session MUST be initialized to zero when that session is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number.  Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less powerful one than whether the record was deprotected. </del> <ins> The received record counter for an association MUST be initialized to zero when that association is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the association.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number.  Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less powerful one than whether the record was deprotected. </ins> Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following

Discussion:
This should make things correct. We might consider getting rid of the term connection or association entirely, but each is problematic: association is a historical term but we also use connection a lot anyway.
It's a shame that "association" is so firmly entrenched. I don't see "association" being used much anyway. Good that you have removed "session" though.
Change:
"blinded_msg" is the Nk-octet request defined above. The Client then generates an HTTP POST request to send to the Issuer, <del> with the TokenRequest as the body.  The media type for this request is "application/private-token-request".  An example request is shown below, where Nk = 512. </del> <ins> with the TokenRequest as the content.  The media type for this request is "application/private-token-request".  An example request is shown below, where Nk = 512. </ins> Upon receipt of the request, the Issuer validates the following conditions:

Discussion:
... I think. I'm double checking to see if there is any other improper HTTP usage.
The Issuance protocol depends on HTTP, so I'd expect this to be cited. Then we get into the HTTP terminology alignment game. For example, where the document says something like should be substituted for as per URL
Change:
"password" value, the credential attribute represents a long-term authentication password, as described in RFC8489, Section 10.2. <del> credential-type: If the Link header represents represents a TURN server, then this attribute specifies how the credential attribute value should be used when that TURN server requests authorization. The default value if the attribute is not present is "password". </del> <ins> credential-type: If the Link header represents a TURN server, then this attribute specifies how the credential attribute value should be used when that TURN server requests authorization.  The default value if the attribute is not present is "password". </ins> There are some webrtc implementations that do not support updating the ICE server configuration after the local offer has been created.

Discussion:
As per
thank you NAME added new changes per your feedback
PATCH request may be received out of order, how do we handle that? ICE candidate, ICE restart reversed order: ICE candidate with old ufrag should be discarded ICE restart, ICE candidate reversed order: Should ICE candidate trigger ICE restart anyway? Agreed solution: use Etag for requests/responses
Change:
even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. <del> 10.4. </del> <ins> 10.3.2. </ins> This event notifies the application of excessive retransmissions, based on a configured threshold (see conn-excss-retransmit).  This

Discussion:
Btw. does this cover all events? There is an issue where I also ask if we e.g. need an event that sending failed due to lifetime expiry. is there a way to double-check if we considered all needed events? Should we also mention ConnectionErrors here? Maybe we anyway need to say more about error?
These are not all events (just search for the word "event" in the document), and generally they are not all lumped together - e.g. sending related events such as "Sent" appear in the "Sending Data" section - which, in fact, has its own subsection called "Send Events". So, this would be a subsection just related to connection management... but then, you state: "During the lifetime of a connection there are events that can occur when configured." which gives the (wrong) impression that this would be the list of all events that can happen during a connection's lifetime. So, I wouldn't add this subsection heading and not include that statement. Or maybe add the subsection heading (which is ok but doesn't help much - as you see, there are only very few events in there), but remove that statement.
+1 to calling this "connection lifecycle events" or similar (do we refer to a connection lifecycle?)
Changed the heading and fixed the nit. I'm open to have another sentence there if people have proposals. We could even have no text but we usually say something after each heading.
Given the new heading, I'm fine with the sentence as it is - because the context is clear now, it's no longer misleading (i.e., giving the wrong impression that these would be ALL events).