jiebi/CodeConvo huggingface dataset:
Change:
A node in the tree may also be _blank_, indicating that no value is present at that node.  The _resolution_ of a node is an ordered list of non-blank nodes that collectively cover all non-blank descendants <del> of the node.  The resolution of a node is effectively a depth-first, left-first enumeration of the nearest non-blank nodes below the node: </del> <ins> of the node.  The resolution of a non-blank node with no unmerged leaves is just the node itself.  More generally, the resolution of a node is effectively a depth-first, left-first enumeration of the nearest non-blank nodes below the node: </ins> The resolution of a non-blank node comprises the node itself, followed by its list of unmerged leaves, if any

Discussion:
In the most basic case, the resolution of a node is the node, so let's say that.
Fwiw this is stated immediately below your note:
Bren2010 said: >Fwiw this is stated immediately below your note: Yes. And it took me three readings to understand that the most complicated scenario was being described first and the most basic scenario is not explicitly stated. Most readers will not understand in what cases there will be unmerged leaves by this point.
Looks good with one minor edit.
Change:
The expression "a URI-reference is _resolved against_ a base URI" is used to describe the process of RFC3986 Section 5.2. <del> Noteworthy corner cases are that resolving an absolute URI against any base URI gives the original URI, and that resolving an empty URI reference gives the base URI. </del> <ins> Noteworthy corner cases are that if the URI-reference is a (full) URI and resolved against any base URI, that gives the original full URI, and that resolving an empty URI reference gives the base URI without any fragment identifier. </ins> A web entity that stores information about web resources and

Discussion:
The previous text did not match my intentions, back when I thought of "absolute URIs" as "URI references that are already in URI form", where actually they are a construct intended for protocols to express that the fragment part does not take part in the dereferencing process. Closes: URL Will merge soon unless it conflicts with someone's private branches or draws other negative comments.
+1 for awareness of the difference between a URI and a reference to a URI
Oh, I see. But then I've been using the term wrong. In ABNF terminology for RFC3986, there's a "URI" (thing-with-scheme), a "relative-ref" and a "URI-reference" (which can be relative or not). I had thought it wise to talk of absolute URIs when I mean thing-with-scheme to disambiguate "URI" from "URI-reference", unaware that "absolute-URI" is even stricter. As we are not designing a communication protocol, we should not use the term "absolute URI", but talk of "URI" or (if ambiguous) a "complete URI". I'll need to patch that in the draft, sorry for the mess and thanks for pointing it out.
Change:
authenticated using an HTTP Authorization header with a Bearer token as specified in RFC6750 section 2.1.  WHIP clients MUST implement this authentication and authorization mechanism and send the HTTP <del> Authorization header in all HTTP request sent to either the WHIP </del> <ins> Authorization header in all HTTP requests sent to either the WHIP </ins> endpoint or resource. The nature, syntax and semantics of the bearer token as well as how

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:
at a time, reducing an exponential-time attack into a linear-time attack. <del> 7.2. </del> <ins> 7.1.1. </ins> QPACK mitigates but does not completely prevent attacks modeled on CRIME (CRIME) by forcing a guess to match an entire field line,

Discussion:
Magnus Nystrom : not be able (based on no current known attack against static Huffman encodings) to mount the previously described "probing" attack? If so, adding a sentence at the end of the section along the lines of "Thus, the previously mentioned probing attack is not known to be applicable for any fields where static Huffman encoding is used."
This section is not related to the probing attack. I think some of the confusion here is lost formatting when importing from RFC 7541. The TOC should be:
Change:
NAT, the WHIP media server SHOULD be publicly accessible. The initial offer by the WHIP client MAY be sent after the full ICE <del> gathering is complete containing the full list of ICE candidates, or only contain local candidates or even an empty list of candidates. </del> <ins> gathering is complete with the full list of ICE candidates, or only contain local candidates or even an empty list of candidates. </ins> The WHIP endpoint SDP answer SHALL contain the full list of ICE candidates publicly accessible of the media server.  The media server

Discussion:
I gave the spec a good read through and would like to propose some minor language edits as my first contribution. Most of these are straight forward such as: WebRTC not webrtc URI not uri signaling not signalling offer/answer not O/A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension. I believe this is incorrect and the intent is that this points at a WHIP resource. I have updated the example as such.
Change:
did not include an "encrypted_client_hello" extension, the client- facing server proceeds with the connection as usual.  The server does not decrypt the second ClientHello's ECHClientHello.payload value, if <del> there is one. </del> <ins> there is one.  Moreover, if the server is configured with any ECHConfigs, it MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys, as described in client-facing-server. </ins> Note that a client-facing server that forwards the first ClientHello cannot include its own "cookie" extension if the backend server sends

Discussion:
This assumes the formulation where, on ECH reject, the server is the client-facing server. In other words, backend servers will never get a CH without ECH having been accepted, so GREASE doesn't apply there. cc NAME
cc NAME too, since he had thoughts on this
Change:
used first. Any ticket MUST only be resumed with a cipher suite that has the same <del> KDF hash as that used to establish the original connection, and only if the client provides the same SNI value as in the original </del> <ins> KDF hash algorithm as that used to establish the original connection, and only if the client provides the same SNI value as in the original </ins> connection, as described in Section 3 of RFC6066. Note: Although the resumption master secret depends on the client's

Discussion:
HKDF-Expand-Label has changed between draft -19 and -20, clarify that "HDF Hash" refers to the hash algorithm and not a version-specific instance of HKDF-Expand-Label which is populated with a hash algorithm.
Change:
the registration or update interface.  The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameters ep and d (sector) does not create <del> multiple registration resources.  A new registration resource may be created at any time to supersede an existing registration, replacing the registration parameters and links. </del> <ins> multiple registration resources. </ins> The following rules apply for an update identified by a given (ep, d) value pair:

Discussion:
The rules laid out below the removed sentence are pretty clear, but the removed sentence itself can be read to contradict them ("may be created at any time to supersede an existing registration") or at best does not add anything. Assuming it was left over from an older version (before the rules were added), I suggest we remove it. NAME that's your section of expertise. Please merge if you agree or reject otherwise.
Change:
"enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. <del> Note that the transport parameter "active_connection_id_limit" QUIC- TRANSPORT limits the number of usable Connection IDs, and also limits the number of concurrent paths.  For the QUIC multipath extension this limit even applies when no connection ID is exposed in the QUIC header. </del> This extension does not change the definition of any transport <del> parameter defined in Section 18.2. of QUIC-TRANSPORT.  Inline with the definition in QUIC-TRANSPORT disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" Section 18.2. of QUIC- TRANSPORT.  Further, it is out of scope for this document to specify if the old address can also be used for multipath after a client has migrated to the address provided in the preferred_address transport parameter.  However, it SHOULD NOT be assumed that it is possible to use both addresses simultaneously without further confirmation from the other host. </del> <ins> parameter defined in Section 18.2. of QUIC-TRANSPORT. Inline with the definition in QUIC-TRANSPORT disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" Section 18.2. of QUIC- TRANSPORT. The transport parameter "active_connection_id_limit" QUIC-TRANSPORT limits the number of usable Connection IDs, and also limits the number of concurrent paths.  For the QUIC multipath extension this limit even applies when no connection ID is exposed in the QUIC header. </ins> 3.

Discussion:
This text will be moved to the next section in PR . Therefore this PR needs to be merged together with PR .
Change:
PSK). The client MUST send a Certificate message if and only if the server <del> has requested client authentication via a CertificateRequest message (certificate-request).  If the server requests client authentication but no suitable certificate is available, the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0).  A Finished message MUST be sent regardless of whether the Certificate message is empty. </del> <ins> has requested certificate-based client authentication via a CertificateRequest message (certificate-request).  If the server requests certificate-based client authentication but no suitable certificate is available, the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0).  A Finished message MUST be sent regardless of whether the Certificate message is empty. </ins> Structure of this message:

Discussion:
Based on the PSK authentication was not included in the past. I think specification has some places where "Client Authentication" refer to only certificate-based client authentication and not client authentication is general. Not a big thing, but I think it might confuse some readers, and would be good to clarify.
Change:
1. HTTP semantics SEMANTICS are used for a broad range of services on <del> the Internet.  These semantics have most commonly been used with two different TCP mappings, HTTP/1.1 and HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC. </del> <ins> the Internet.  These semantics have most commonly been used with HTTP/1.1, over a variety of transport and session layers, and with HTTP/2 over TLS.  HTTP/3 supports the same semantics over a new transport protocol, QUIC. </ins> 1.1. <del> HTTP/1.1 HTTP11 is a TCP mapping which uses whitespace-delimited text fields to convey HTTP messages.  While these exchanges are human- readable, using whitespace for message formatting leads to parsing complexity and motivates tolerance of variant behavior.  Because HTTP/1.x does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel.  However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections. </del> <ins> HTTP/1.1 HTTP11 uses whitespace-delimited text fields to convey HTTP messages.  While these exchanges are human-readable, using whitespace for message formatting leads to parsing complexity and excessive tolerance of variant behavior.  Because HTTP/1.x does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel.  However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections. </ins> HTTP/2 HTTP2 introduced a binary framing and multiplexing layer to improve latency without modifying the transport layer.  However,

Discussion:
The introduction is oddly narrow about HTTP/1.1 (and h2) being a TCP mapping, even though HTTP/1.x is commonly used on many different transports and session-layers. In fact, it was specifically designed to not be dependent on TCP so that it could be implemented over every network and every security layer. A simple solution would be to delete that as a description, since it is neither accurate nor useful. It's fine to say that HTTP/3 is specific to QUIC.
Change:
receiver will be able to verify which is the sender of the media coming within the RTP stream at any given point if time, preventing the SFU trying to impersonate any of the participants with another <del> participant's media.  Note that in order to prevent impersonation by a malicious participant (not the SFU) usage of the signature is required.  In case of video, the a new signature should be started each time a key frame is sent to allow the receiver to identify the source faster after a switch. </del> <ins> participant's media. Note that in order to prevent impersonation by a malicious participant (not the SFU), a mechanism based on digital signature would be required.  SFrame does not protect against such attacks. </ins> 6.1.2.

Discussion:
The signature mechanism was removed from SFrame some time ago. This PR removes a few remaining references to it.
Seems good but needs rebasing
NAME NAME I think we are ok to merge this PR?
Change:
4.1.3. The server will send this message in response to a ClientHello <del> message when it was able to find an acceptable set of algorithms and the client's "key_share" extension was acceptable.  If it is not able to find an acceptable set of parameters, the server will respond with a "handshake_failure" fatal alert. </del> <ins> message if it is able to find an acceptable set of parameters and the ClientHello contains sufficient information to proceed with the handshake. </ins> Structure of this message:

Discussion:
This is a giant pile of nitpicks, loosely inspired by the FFDHE alert discussion. The old text specifies a handshakefailure which is redundant with and contradicts the Cryptographic Negotiation section. The old text says only handshakefailure is allowed while Cryptographic Negotiation allows both handshakefailure and insufficientsecurity. Fix this by avoiding redundancy as the failure cases are global to the overall negotiation algorithm. Next, align the tense with itself and the rest of the text. Most of the text appears to be written in present tense. The old text for SH said: The server will send [...] when it was able to [...] which is a little odd. Also align the wording between the two. Talk about a server (singular) to match Cryptographic Negotiation and say "parameters" rather than "algorithms" or "algorithms and groups". Also be consistent about the SH vs. HRR condition. The SH section said "the client’s key_share extension was acceptable" while the HRR section said "the client’s ClientHello did not contain sufficient information to proceed with the handshake". Use the more general one.
Seems reasonable. I a little bit wondered whether to replace "it" with "the server", but the pronoun's meaning should be clear, here.
Seems clear enough to me, but I'm equally happy with the other wording. shrug
This does seem clearer. And shorter!
Change:
attacks, but downgrades have no security implications, as the version properties are identical. <del> 7. </del> <ins> 8. </ins> This document requests that IANA add the following entry to the QUIC version registry:

Discussion:
One way to
I have a feeling you'll need to say that this "updates" HTTP/3.
on slack some are saying we should roll a new h3 ALPN for running over quicv2. I cannot quite follow the argument but this is a better venue for the discussion.
You definitely need a new specification, because a different QUIC version might not be suitable. You either say: h3 can be used with QUICv2, or h3q2 (or whatever new string you like) identifies HTTP/3 when running over QUICv2. There are lots of arguments as to why you might choose to do one or the other.
I'm swayed more toward a new ALP.N at the moment
FWIW we painted ourselves into this corner. We punting on the problem and simply tied H3 to v1. Now we are actively trying to solve VN we might be able to pay back the tech debt. For example, a document that updates H3 to say that it can work over versions compatible with v1. Incompatible versions could still need to defined as a new application mapping,
Whatever we do, I think we need to ensure that servers can give sufficient information to clients via Alt-Svc so that the client can pick a compatible version (if any) and avoid VN. This could, then, be solved via Alt-Svc layer or via ALPN, but I think this is any important property.
Well "avoiding VN" is only important to the extent that we can't do compatible VN.
I think we want to allow the existence of a server that only supports v2 and servers that only support v1.... and clients that only support v2 and clients that only support v1. Given this, there will be client : server pairs which do not support any mutually compatible options. It seems like it would be desirable for clients to be able to deduce this from Alt-Svc without needing to see the QUIC connection to the server fail?
Oh, and this text from the HTTP/3 docs is probably relevant:
Change:
Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m=" section(s) and further processing of the RTP/RTCP is done at the <del> RtpTransceiver level.  This includes using RID RFC8851 to distinguish between multiple encoded streams, as well as to determine which </del> <ins> RtpTransceiver level.  This includes using the RID mechanism RFC8851 and its associated RtpStreamId and RepairedRtpStreamId identifiers to distinguish between multiple encoded streams and determine which </ins> Source RTP stream should be repaired by a given redundancy RTP stream.

Discussion:
This also adds in a sentence about using the MID header extension in outgoing streams, which was previously omitted despite there being a corresponding sentence for incoming streams.
The comment "[rfced] Please let us know if any changes are needed for the..." should also be removed.
AUTH48 on this document started with sixty [rfced] questions sent to the authors (NAME NAME NAME 2020 July 7. These questions were added as GitHub issues through . Follow on issues were created (in particular, splitting issues and ) to isolate some of the questions and to review normative text (). When PR is merged, all AUTH48 [rfced] questions will have been addressed, but there are some remaining XML comments that need to be removed.
This is sort of nuts but LGTM
Change:
registration in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise. <del> To change the key associate with an account, the client sends a POST </del> <ins> To change the key associated with an account, the client sends a POST </ins> request containing a key-change object with the following fields: The JWK representation of the original key (i.e., the client's

Discussion:
Fixing two minor typos in Section 6.2.1 "Account Key Roll-over"
Change:
..., 23 is just copied directly into the message, a byte string which doesn't is encoded as a CBOR bstr during transport. <ins> Implementation Note: When implementing the byte string identifier representation it can in some programming languages help to define a new type, or other data structure, which (in its user facing API) behaves like a byte string, but when serializing to CBOR produces a byte string or an integer depending on its value. </ins> 3.3.3. For OSCORE, the choice of connection identifier results in the

Discussion:
. First text based on initial draft by Christian.
On request. Some people have already implemented this and may want to comment on the Implementation Note in PR .
Merged
Change:
A P-Route may be installed in either Storing and Non-Storing Mode, potentially resulting in hybrid situations where the Mode of the <del> P-Route is different from that of the RPL Main DODAG.  P-Routes can be used as stand-alone segments to reduce the size of the source routing headers with loose source routing operations down the main RPL DODAG.  P-Routes can also be combined with other P-Routes to form a more complex forwarding graph called a Track. </del> <ins> P-Route is different from that of the RPL Main DODAG. P-Routes can be used as stand-alone segments to reduce the size of the source routing headers with loose source routing operations down the main RPL DODAG.  P-Routes can also be combined with other P-Routes to form a more complex forwarding graph called a Track. </ins> 3.3.

Discussion:
Comments on the content In the XML file you can search for "COMMENT:". In the TXT file, the comments start with "_COMMENT:"
I'll address inline and commit too. Many thanks Aris!!!
Change:
Finally, generic errors are provided for conditions where implementations are unable or unwilling to use more specific codes. <del> 20.1. </del> <ins> 20.2. </ins> <del> Application protocol error codes are 62-bit unsigned integers, but the management of application error codes is left to application </del> <ins> The management of application error codes is left to application </ins> protocols.  Application protocol error codes are used for the RESET_STREAM frame (frame-reset-stream), the STOP_SENDING frame (frame-stop-sending), and the CONNECTION_CLOSE frame with a type of

Discussion:
The current structure is incorrect, because application error codes is a subsection of transport error codes, despite application error codes being disjoint from transport error codes.
Wonderful. Thank you.