jiebi/CodeConvo huggingface dataset:
Change:
or MAY take no action. When a server sends CANCEL_PUSH, it is indicating that it will not be <del> fulfilling a promise and has not created a push stream.  The client should not expect the corresponding promise to be fulfilled. </del> <ins> fulfilling a promise.  The client cannot expect the corresponding promise to be fulfilled, unless it has already received and processed the promised response.  A server SHOULD send a CANCEL_PUSH even if it has opened the corresponding stream. </ins> Sending CANCEL_PUSH has no direct effect on the state of existing <del> push streams.  A server SHOULD NOT send a CANCEL_PUSH when it has already created a corresponding push stream, and a client SHOULD NOT send a CANCEL_PUSH when it has already received a corresponding push stream.  If a push stream arrives after a client has sent CANCEL_PUSH, this MAY be treated as a stream error of type H3_STREAM_CREATION_ERROR. </del> <ins> push streams.  A client SHOULD NOT send a CANCEL_PUSH when it has already received a corresponding push stream.  A push stream could arrive after a client has sent CANCEL_PUSH, because a server might not have processed the CANCEL_PUSH.  The client SHOULD abort reading the stream with an error code of H3_REQUEST_CANCELLED. </ins> A CANCEL_PUSH frame is sent on the control stream.  Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be

Discussion:
by reversing the polarity of a SHOULD. Doesn't break interop, but it's always safer to send CANCEL_PUSH than to omit it, so let's not recommend omitting it under any circumstances.
The spec suggest that a server should send a CANCELPUSH to notify a client that it will not fulfill a PUSHPROMISE. The server should send CANCELPUSH before a push stream has been open. The server still can cancel a push stream after it has been created and that will have a similar effect as a CANCELPUSH frame. There is a small problem with that. If the server resets a push stream before client starts reading, the client may have not read the pushid from the stream and that pushid will never be fulfill or cancel for the client point of view. Should there be a sentence in the spec explaining this? Probably suggesting not to cancel a push stream until server is certain that client has read it, which is difficult. Should the spec suggest ot send CANCEL_PUSH even after a push stream has been created?
The server doesn't need to ensure that the push ID is read if CANCELPUSH is used, mostly. If the stream type is read, but not the push ID (which is entirely possible), then the client will know that there was a push and that it didn't happen, but can't connect that with the promise or cancellation. In that case, clients need to handle that. In fact, this highlights the value of CANCELPUSH in the case where the stream is reset.
This will not break interop either way. We can change the recommendation easily.
This issue and its fix has been pretty well discussed already. The proposal is borderline on a design change, so I've marked this as design to get some visibility during the next consensus call.
lgtm
Change:
10. <del> This document registers the quic_transport_parameters extension found in quic_parameters in the TLS ExtensionType Values Registry TLS- REGISTRIES. </del> <ins> IANA has registered a codepoint of 57 (or 0x39) for the quic_transport_parameters extension (defined in quic_parameters) in the TLS ExtensionType Values Registry TLS-REGISTRIES. </ins> <del> The Recommended column is to be marked Yes. The TLS 1.3 Column is to include CH and EE. </del> <ins> The Recommended column for this extension is marked Yes. The TLS 1.3 Column includes CH and EE. </ins>

Discussion:
Also, examples use final version numbers. IMPORTANT: the TLS extension codepoint needs to be updated, both in the text and in the examples (which will result in changes to authentication tags and the affected ciphertext).
I plugged the test vectors into the quiche test suite and it checks out URL
Hey there! We are currently implementing the Initial packet encryption process and it successfully works with the client Initial example from the appendix A.2 of the QUIC-TLS draft. However, when running tests with values for the server Initial example from the appendix A.3, tests regarding the parsing, header sampling, header protection and final encryption result all succeed, except for the header protection mask: the value we generate is: , while the draft explicitly specifies it should be something completely different: . Note that the value we generate is indeed used later on for the header protection and final encryption result, which both reveal successful. Therefore, three possibilities we thought of, in ascending order of probability: Our implementation is completely broken. The mask value provided by the current version of the specification (A.3) is correct, but all others are incorrect. Only the mask value is incorrect, while the rest is correct. We think the last option is the most probable one, as it could just mean it was forgotten to be updated in a recent draft version. If you think this is the case as well, then I would gladly open up a PR in order to close this, I just wanted to make sure beforehand. Otherwise, I would happily accept a tad of guidance towards a correct implementation. Thanks in advance, Paul.
Investigated a bit more. Looking at the result of a , we can see that: 2ebdfd53a is indeed meant to update example vectors, but does it only partially it seems: while 2ebdfd53a is for other secrets, but did it completely. So it should confirm our hypothesis.
hi NAME Our editors are taking some slight respite, we'll respond soon.
No problem NAME I was just adding some more information I forgot to mention yesterday. Thanks for the heads up :+1:
It seems to me that the header is not correct. Thoughts?
For me the header looks fine: it is consistent with the final result. What looks wrong to you NAME
I'll assign this to NAME since I think that is his code.

I can confirm this, but it won't matter as -33 will have new values entirely. The mask value should be 56fb1381e7 for the second example.
NAME would you link this issue to the PR that will update the values for -33 so it gets closed then?
New values seem to work in my testing.
Change:
If the participants in a call have a pre-existing E2E-secure channel, they can use it to distribute SFrame keys.  Each client participating <del> in a call generates a fresh encryption key and optionally a signing key pair.  The client then uses the E2E-secure channel to send their encryption key and signing public key to the other participants. </del> <ins> in a call generates a fresh encryption key.  The client then uses the E2E-secure channel to send their encryption key to the other participants. </ins> In this scheme, it is assumed that receivers have a signal outside of SFrame for which client has sent a given frame, for example the RTP

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:
server can promise.  A server SHOULD use Push IDs sequentially, starting at 0.  A client MUST treat receipt of a push stream with a Push ID that is greater than the maximum Push ID as a connection <del> error of type HTTP_LIMIT_EXCEEDED. </del> <ins> error of type HTTP_ID_ERROR. </ins> The header of the request message is carried by a PUSH_PROMISE frame (see frame-push-promise) on the request stream which generated the

Discussion:
Implements suggestions from
Updated to replace HTTPLIMITEXCEEDED and HTTPPUSHIDERROR with the single error HTTPID_ERROR.
There are presently a few cases where the Push ID can be used incorrectly. The table shows current error codes, proposes replacing the HTTPDUPLICATEPUSH with an HTTPPUSHIDERROR code, and replaces use of HTTPMALFORMED frame. Note, on I suggested a slightly different solution to replace HTTPMALFORMED FRAME, but I think this is a better path.
To me it seems that having an error code for specific part of push (i.e. ID of push-related information being incorrect) a bit too detailed. I think it sticks out, because we do not have things like "IDERROR, STREAMIDERROR. Also, using PUSHIDERROR in some cases while using MALFORMEDFRAME in others seems confusing. I think we might want to consider doing either of the two: Use PUSHIDERROR (or a generic error code for push) for all the push-related errors. This makes sense if we consider push as an optional feature of HTTP/3 Introduce IDERROR that captures all the limit and ID errors.
Thanks NAME The proposal is a bit of a compromise, so I agree with some of the points that you make. I like your idea of replacing HTTPLIMITEXCEEDED with HTTPIDERROR. I think it solves the issue in the most general way and doesn't change the protocol mechanics. What follows is the response I made first, before coming to that agreement :) Right. The difference here is that H3 frames only reference the stream and placeholder ID spaces, they don't control them. So, if the peer references an ID that doesn't exist then respond with HTTPLIMITEXCEEDED. Multiple references to the same ID is a little different, its ok to reuse placeholder ID (as long as the above condition holds, and you create a semantically valid PRIORITY frame). The transport spec discusses reuse of stream IDs at that layer; in H3 we only use stream ID for PRIORITY and GOAWAY - this has similar restrictions. However, server push is a little different because it's ID space is managed by the MAXPUSHID frame. The three errors that use HTTPPUSHIDERROR are unique to push.

However, if we modified HTTPLIMITEXCEEDED to cover exceeding limits and incorrect ID usage (call it HTTPID_ERROR) I think that would work.
I updated the PR with the above, so that we can see what it looks like.
I'm not totally sold on this, but I'm having trouble articulating what it is that doesn't flow for me. I suspect that means I don't actually disagree, I just need some time to wrap my head around it.
We merged so I'm closing this as completed.
Change:
A "dot-member-name-shorthand" of the form ".<member-name>" is shorthand for "['<member-name>']", but can only be used with member names that are composed of certain characters.  Thus, for example, <del> "$.foo.bar" is shorthand for "$['foo']['bar']" (and not for </del> <ins> "$.foo.bar" is shorthand for "$['foo']['bar']" (but not for </ins> "$['foo.bar']"). 2.7.1.2.

Discussion:
Signed-off-by: Tim Bray Nothing fancy here, just like the title says.
LGTM, thanks.
Change:
If the HTTP PATCH request results in an ICE restart, the WHIP resource SHALL return a "200 OK" with an "application/trickle-ice- sdpfrag" body containing the new ICE username fragment and password. <del> The response may optionally contain the new set of ICE candidates for the Media Server and the new entity-tag correspond to the new ICE session in an ETag response header field. </del> <ins> Also, the "200 OK" response for a sucesscull ICE restart MUST contain the new entity-tag corresponding to the new ICE session in an ETag response header field and MAY contain a new set of ICE candidates for the Media Server. </ins> If the ICE request cannot be satisfied by the WHIP resource, the resource MUST return an appropriate HTTP error code and MUST NOT

Discussion:
NAME ping?
“The response may optionally contain the new set of ICE candidates for the Media Server and the new entity-tag correspond to the new ICE session in an ETag response header field.” Is this really meant to indicate that the new ICE candidates AND the new entity-tag are optional? I would have expected that after an ICE restart a new entity-tag is required.
The optionally only applies to the first part of, will reword it.
Change:
the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in <del> accordance with RFC7022.  [OPEN ISSUE: How are CNAMEs specified for MSTs?  Are they randomly generated for each MediaStream?  If so, can two MediaStreams be synced?  See: https://github.com/ rtcweb-wg/jsep/issues/4] </del> <ins> accordance with RFC7022 and sec.cname. </ins> If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in

Discussion:
This Replaces PR URL This fixes URL
I cleaned up the text here.
The structure of this looks good - just think the text should be expanded a bit.
This should incorporate the change in - and reference URL there as well.
lgtm
While cname for offers is described quite clearly, the sections describing answers don't mention CNAME.
This should get handled in NAME
I don't think that is the place. Looking at section 5.3.1. Initial answer, there is text saying 'If a local MediaStreamTrack has been associated, an "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media.' There should be something about cname here as well, just as it is for the corresponding part in section 5.2.1 Initial Offer.
Right, but is making changes to 5.2.1, so that's probably the right place to change 5.3.1 as well.
I saw Ekr updated and closed this one. Makes sense. , Justin Uberti EMAIL wrote:
Section 5.2.1: in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs specified for MSTs? Are they randomly generated for each MediaStream? If so, can two MediaStreams be synced?]
Discussion on rtp usage more or less concluded that we'd use the same CNAME for an entire RTCPeerConnection, unless the tracks had different clock sources. And require different CNAMEs for different RTCPeerConnections, unless something had forced them to be the same. API affordances for this are TBD and for the W3C WG, Magnus suggested some sort of binding between RTCPeerConnection instances to allow for CNAME copying, rather than provide the footgun that direct overwriting permits (i.e., the browser is given the ability to mark unsynchronized tracks differently, rather than be forced to falsely claim synchronization).
Discussed in DC: this resolution is OK. Question about the use of LS groups for legacy gear, as opposed to MSID. See .
Related but URL
What are next steps here?
Propose browser generates one CNAME (or more if multiple clock sources). Later API may add ways to set the CNAME from JS.
That would be consistent with the RTP usage conclusions.
Change:
2.1. This document uses the terminology established in the DetNet <del> architecture I-D.ietf-detnet-architecture, and the reader is assumed to be familiar with that document and its terminology. The following terminology is introduced in this document: A Detnet "forwarding" label that identifies the LSP used to forward a DetNet flow across an MPLS PSN, e.g., a hop-by-hop label used between label switching routers (LSR). A DetNet "service" label that is used between DetNet nodes that implement also the DetNet service sub-layer functions.  An S-Label is also used to identify a DetNet flow at DetNet service sub- layer. A DetNet Control Word (d-CW) is used for sequencing and identifying duplicate packets of a DetNet flow at the DetNet service sub-layer. </del> <ins> architecture I-D.ietf-detnet-architecture and I-D.ietf-detnet-mpls, and the reader is assumed to be familiar with that document and its terminology. </ins> 2.2. The following abbreviations are used in this document: <del> Attachment Circuit. Customer Edge equipment. Class of Service. </del> Control Word. Deterministic Networking. DetNet Flow. <del> DetNet Inter-Working Function. </del> <ins> Frame Replication and Elimination for Redundancy (TSN function). </ins> Layer 2. <del> Layer 2 Virtual Private Network. </del> Layer 3. Label Switching Router. Multiprotocol Label Switching. <del> Multiprotocol Label Switching - Traffic Engineering. Multiprotocol Label Switching - Transport Profile. Multi-Segment PseudoWire (MS-PW). Native Service Processing. Operations, Administration, and Maintenance. </del> Provider Edge. <del> Packet Elimination Function. Packet Replication Function. </del> Packet Replication, Elimination and Ordering Functions. <del> Packet Ordering Function. </del> Packet Switched Network. PseudoWire. <del> Quality of Service. </del> Switching Provider Edge. Terminating Provider Edge. Time-Sensitive Network. <del> 3. </del> <ins> 2.3. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Discussion:
Similar structure and changes as in IP over TSN. Service protection interworking is out-of-scope.
Change:
ServerHello, and HelloRetryRequest. epoch value (1) is used for messages protected using keys derived <del> from client_early_traffic_secret.  This includes early data sent by the client and the EndOfEarlyData message. </del> <ins> from client_early_traffic_secret.  Note this epoch is skipped if the client does not offer early data. </ins> epoch value (2) is used for messages protected using keys derived from [sender]_handshake_traffic_secret.  Messages transmitted

Discussion:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?
Change:
wishes to use four datagram flows for the lifetime of its request stream could look like this: <del> In this example, 42 is the unnamed flow, 44 represents the name "ecn- ect0", 46 represents "ecn-ect1", and 48 represents "ecn-ce".  Note that, since the list ordering does not carry semantics, this example can be equivalently encoded as: </del> <ins> In this example, 42 is the unnamed flow, 44 represents the name "foo", 46 represents "bar", and 48 represents "baz".  Note that, since the list ordering does not carry semantics, this example can be equivalently encoded as: </ins> Even if a sender attempts to communicate the meaning of a flow before it uses it in an HTTP/3 datagram, it is possible that its peer will

Discussion:
Currently, the Datagram-Flow-Id Header Field Definition section contains examples of the Datagram-Flow-Id header, which includes a 4-flow mechanism for conveying ECN information: This example seems to be tripping people up, myself included, by attempting to solve a problem of in-band signaling of non-UDP-payload bits by providing these streams, and drawing attention to that problem rather than the capability being described. I propose we remove this example until we have a better one to replace it. If we cannot find a good example, that also lends some evidence that perhaps we don't need the feature of creating multiple Datagram-Flow-Id associations in the same request.
Change:
Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits and B can be omitted to <del> indicate no set upper limit; values in this format always end on an byte boundary </del> <ins> indicate no set upper limit; values in this format always end on a byte boundary </ins> Indicates that x has a fixed value of C with the length described by L, which can use any of the three length forms above

Discussion:
Draft 34 changed notation from "octet" to "byte" in a few places, but forgot to change the article in two places.
Thanks, NAME
Change:
For DTLS, all m= sections MUST use all the certificate(s) that have been specified for the PeerConnection; as a result, they MUST all <del> have the same I-D.ietf-mmusic-4572-update fingerprint value(s), or these value(s) MUST be session-level attributes. </del> <ins> have the same RFC8122 fingerprint value(s), or these value(s) MUST be session-level attributes. </ins> Each m= section should be generated as specified in RFC4566, Section 5.14.  For the m= line itself, the following rules MUST be

Discussion:
I don't know why build of ghpages is failing travis. It works for me on my machine so going to ignore this for a bit.
Here is the diff of the change.
BLOCKER: The nits tool reports (and a cursory hand check supports this) that six of the references are unused, and RFC4572 has been (recently) obsoleted. The remaining references are largely out of date by many versions, which I believe the current tools will automatically handle if version numbers are simply pulled out of the source. Finally, a large number of the referenced working group documents still use the individual name (e.g., draft-nandakumar-rtcweb-sdp instead of draft-ietf-rtcweb-sdp).
Need to verify section numbers when these refs change, but otherwise seems fine.
LGTMLG, assuming this generates the equivalent text.
Change:
QUIC connections are shared state between a client and a server INV. The compatible version negotiation mechanism defined in this document <del> (see compat-vn) operates inside of a QUIC connection; i.e., the packets with the original version are part of the same connection as the packets with the negotiated version.  On the other hand, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see incompat-vn) conceptually operates across two QUIC connections: one before the Version Negotiation packet, and a distinct connection after. </del> <ins> (see compat-vn) is performed as part of a single QUIC connection; that is, the packets with the original version are part of the same connection as the packets with the negotiated version. In comparison, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see incompat-vn) conceptually operates across two QUIC connections: the connection attempt prior to receiving the Version Negotiation packet is distinct from the connection with the incompatible version that follows. </ins> 4.2.

Discussion:
No real complaint with what existed before, but I thought that this might be clearer.
Approved with one nit
Change:
Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through <del> "0x&#8237;3FFFFFFFFFFFFFFE&#8236;") MUST NOT be assigned by IANA. </del> <ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. </ins> 10.4.

Discussion:
This was fun, it turns out there were actually 3 pair of instances where the were added. I wonder if this was super meta level protest against the endianess-swap from back in the day...
Draft 19 has rendering issue for the reserved frame type in section 10.4
Change:
15. <ins> Thomas Hardjono created older versions of the terminology section in collaboration with Ned Smith.  Eric Voit provided the conceptual separation between Attestation Provision Flows and Attestation Evidence Flows.  Monty Wisemen created the content structure of the first three architecture drafts.  Carsten Bormann provided many of the motivational building blocks with respect to the Internet Threat Model. 16. </ins> The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time such as Coordinated

Discussion:
this is not complete and does not pass xml2rfc yet. Please add/fix your name/email. Or remove your email. Or foo at example dot com it.