jiebi/CodeConvo huggingface dataset:
Change:
lines, as specified in RFC4566, Section 6, and RFC3264, Section 6.1. <del> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, as described in sec-create-offer. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </del> If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an

Discussion:
It's a transport attribute, so it should come at the end, like other transport attribs
just checking ... this is just a style thing right? the code would accept SDP with these in any order ?
Of course. This is just how we order things in Section 5.
For createoffer, createanswer ordering of attribs
So SDP has no requirement on the ordering of the a= lines. I don't see how a parser, even a JSEP one can expect to get the a= lines in any specific order. I fear that even a "it is recommended to generate them in this order" will be misinterpreted. I think this is one of SDPs warts that you will have to live with.
Right, there isn't any need to mandate an order, I just think that in the text for generating an offer, the places that talk about adding a=rtpmap should be adjacent. This should be a fairly trivial editorial change.
Change:
that is reset by revealing the Stateless Reset Token MUST NOT be reused for new connections at nodes that share a static key. <del> The same Stateless Reset Token MAY be used for multiple connection IDs on the same connection.  However, reuse of a Stateless Reset Token might expose an endpoint to denial of service if associated connection IDs are forgotten while the associated token is still active at a peer.  An endpoint MUST ensure that packets with Destination Connection ID field values that correspond to a reused Stateless Reset Token are attributed to the same connection as long as the Stateless Reset Token is still usable, even when the connection ID has been retired.  Otherwise, an attacker might be able to send a packet with a retired connection ID and cause the endpoint to produce a Stateless Reset that it can use to disrupt the connection, just as with the attacks in reset-oracle. </del> <ins> The same Stateless Reset Token MUST NOT be used for multiple connection IDs.  Endpoints are not required to compare new values against all previous values, but a duplicate value MAY be treated as a connection error of type PROTOCOL_VIOLATION. </ins> Note that Stateless Reset packets do not have any cryptographic protection.

Discussion:
The editors assumed this was true, but I think it's worth stating this as a MUST to ensure clarity.
I'm a bit worried this misses the point. Ack-eliciting packets should be acknowledged yes, but so should non-ack-eliciting packets. By stating that ack-eliciting packets should be ACK'ed at least once, it is implied that this is not the case for other packets. This may be correct but not necessarily clear. For example for long transmissions where the peer does nothing but sending ACKs, not all of those ACKs will necessarily have to be ACK'ed. But what is the guiding principle for that? And, since you in this case are sending lots of ACK eliciting packets, you can easily ACK all the peers ACK's. So when would you not want to do that? A special case that could deadlock - e.g. too many ACKs to fit in a packet?
Also, when ACKs packets don't fit in packets, this would also hold for ACK'ing ack-eliciting packets. So you could end up having to not ACK'ing some packets and induce loss. Requiring an ACK for all packets would be problematic. I'm not sure we want that. The result could be very hard to implement while the practical benefit would be small: sending multiple ACK packets with different content due to overflow.
I just synced to master and now this seems to be an editorial change, at least to me. That being said, PTAL at the text and tell me if there are any other changes I should make.
It appears that the spec doesn't actually require sending ACKs for every ACK-eliciting packet. This could lead to a perverse implementation just not ACKing things with obvious problems.
Discussed in Cupertino. Add normative language to prescribe what should be ACKed. Reclassifying as Editorial (adds normative language, but we have consensus on that).
Generally looks good, but I don't think we can have an absolute requirement that every ack-eliciting packet is acknowledged.
Change:
5.4. <del> To verify a token, a verifier creates a VOPRF context, evaluates the token contents, and compares the result against the token authenticator value, as follows: </del> <ins> To verify a token, a verifier creates a VOPRF context using the Issuer Private Key, evaluates the token contents, and compares the result against the token authenticator value, as follows: </ins> 5.5.

Discussion:
Hexadecimal constants are used as strings without specifying the length or byte order. For example, "0x0001" might be interpreted in a couple of ways. Usually the correct interpretation is clear in context, but I'm not sure it always is.
[ ] Overall: The document is inconsistent about capitalization after colon (":"). [ ] Abstract: I'm not sure the distinction between public/private verifiability is common knowledge. It might be helpful to say plainly who is doing the verifying. E.g.: "one [variant] providing tokens whose validity can be verified by the issuer only; and another for which token validity can be verified by any party with the issuer public key." [ ] 2 Terminology: "We assume that all protocol messages are encoded into raw byte formatt before being sent across the wire" This doesn't need to be mentioned, in my opinion. [ ] 5.1 Client-To-Issuer Request: The psedocode for computing "client_context" hard-codes a particular OPRF suite (0x0004). Is this the only suite that is permitted/recommended by the document? I don't think this is clear until the token types are defined in Section 8.1. [ ] 5.3 Finalization: Constants hardcoded instructs don't a semi-colon after the constant. (See "Token" in this section, for example.) Is this intentional? It looks a bit odd, and I'm wondering if this is "syntactically" correct. [ ] 5.4 Token Verification: I think it's worth pointing out here that creating the server context requires the Issuer Private Key, which is why VOPRF is not publicly verifiable. [ ] 7 Security Considerations: "All security considerations described in the VOPRF document also apply in the Privacy Pass use-case." What about security considerations for BLINDRSA? It might be a bit cleaner to write something like this: "Each protocol described here inherits the security considerations of its base document: For Section 5, this is [VOPRF]; ... " [ ] Acknowledgements: Sofi is acknowledged, but is also a co-author.
I think I caught all of these. Addressed in . Yes, this is much better! Addressed in .

This is addressed by . We explain the constant in the sentence immediately following the pseudocode, so I don't think further clarification is needed. The semi-colon was missing, but we updated this to match what's done in RFC8446. Addressed in . Addressed in . Good catch. This has already been fixed on the editor's branch to say "All security considerations described in the VOPRF and blind RSA documents also apply in the Privacy Pass use-case."
Change:
false This property specifies that a message should be sent and received as <del> a single packet network-layer fragmentation, if possible.  Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError".  When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set. </del> <ins> a single packet without network-layer fragmentation, if possible. Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError".  When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set. </ins> 7.6.

Discussion:
I also added a link to NEATPy in the overview of implementations, and inserted a missing word in interface (a missing "without", must have been a nit)
It might be worth to better align the sections on Message Properties in the API and Implementation draft. Note that e.g. "Final" has more implementation details in the API draft than in the implementation draft.
Change:
Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not, <del> the server SHOULD reply with status code 404 (Section 6.5.4 of RFC7231).  If it does, it MAY accept the session by replying with a </del> <ins> the server SHOULD reply with status code 406 (Section 15.5.7 of RFC9110).  If it does, it MAY accept the session by replying with a </ins> 2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.

Discussion:
Change 404 to 406 Not Acceptable
Current text: >Upon receiving an extended CONNECT request with a field set to , the HTTP server checks if the identified resource supports WebTransport sessions. If the resource does not, the server SHOULD reply with status code 404 ({{Section 6.5.4 of !RFC7231}}). If it does, it MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of {{!SEMANTICS=I-D.ietf-httpbis-semantics}}. The WebTransport server MUST verify the header to ensure that the specified origin is allowed to access the server in question. Originally posted by NAME in URL
The corresponding text in HTTP/3 appears to be: This is correct, though I am not sure how necessary it is.
Discussed in editor's call: 406 sounds good
Change:
The User Equipment: None of the above requirements are mandatory because (a) we do not <del> wish to say users or devices must seek full access to the captive network, (b) the requirements may be fulfilled by manually visiting </del> <ins> wish to say users or devices must seek full access to the Captive Portal, (b) the requirements may be fulfilled by manually visiting </ins> the captive portal web application, and (c) legacy devices must continue to be supported.

Discussion:
A reviewer found a problem with some phrasing, and also noticed that we missed a few captive networks. Clean them up.
Change:
Some examples: <ins> 3.5.9. The list selector allows combining member names, array indices, and slices in a single selector. Note: The list selector was called "union selector" in JSONPath-orig, as it was intended to solve use cases addressed by the union selector in XPath.  However, the term "union" has the connotation of a set operation that involves merging input sets while avoiding duplicates, so the concept was renamed into "list selector". 3.5.9.1. The list selector is syntactically related to the "index-selector" and the "slice-selector".  It contains two or more entries, separated by commas. 3.5.9.2. A list selector selects the nodes that are selected by at least one of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one of the selector entries is kept as many times in the node list. To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem- overview. </ins> 3.6. A Normalized Path is a JSONPath with restricted syntax that

Discussion:
To do: [x] Consider reorganising selectors in section 3.3 to match the order of the document [x] Consider reorganising table 1 to match the order of the document Fixes URL
Reorganised selectors in section 3.3 to match the order of the document. Did not reorganise table 1 as it flows better as is.
Filter selectors should come before list selectors to avoid a forward reference. The following comment should be deleted: Also, as noted by NAME at today's interim WG meeting, we should factor out a separate production to avoid repeating here: and here: Possible names for this production: or .
I think we proposed something like ... and here: thanks.
(And once we are don't with this issue, we can reorder table 1. Not quite sure if we want to do this entirely in section order; let's see how that turns out first.)
Change:
support.  For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is <del> desired.  For example, when using the Opus codec, the "usedtx=1" parameter would be specified in the offer.  This option allows the endpoint to significantly reduce the amount of audio bandwidth it receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. </del> <ins> desired.  For example, when using the Opus codec RFC6716, the "usedtx=1" parameter, specified in RFC7587, would be used in the offer.  This option allows the endpoint to significantly reduce the amount of audio bandwidth it receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. </ins> If the "VoiceActivityDetection" option is specified, with a value of "false", the JSEP implementation MUST NOT emit "CN" codecs.  For

Discussion:
Since the second ref is so close to the first, I decided it wasn't needed.
Yes, we need a reference for 7587, since we talk about usedtx. It might make sense to have one for 6716 as well in S 5.2.3.2.
Looks good. Do you think we need a similar ref to 7587 in the para that discusses dtx=0?
Change:
frames and can also be used to provide protection against traffic analysis or for other reasons. <del> The padding extends to the end of the WT_PADDING frame and that many bytes can be discarded by the recipient. </del> <ins> The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field. </ins> 5.2.

Discussion:
The frame format depends on having a definition. I've also made a requirement for this to be zero values. Do we need to say that recipients MUST NOT validate this or that they MAY opt to avoid validation.
Change:
verify the JWS (i.e., the "jwk" element of the JWS header) to authenticate future requests from the account.  The server returns this account object in a 201 (Created) response, with the account URL <del> in a Location header field. </del> <ins> in a Location header field.  The account URL is used as the "kid" value in the JWS authenticating subsequent requests by this account (See request-authentication). </ins> 7.3.1.

Discussion:
Section 6.2 "Request Authentication" says: Prior to this commit Section 7.3 "Account Creation" doesn't mention that the account URL also doubles as the key ID. To make the question of "What is my Key ID?" more obvious for client implementers this commit adds a brief mention of this fact where the specification discusses the account URL. Thanks to NAME for flagging this and providing a chance to avoid confusion and add clarity.
thanks
Change:
If the decryption fails, a fatal "bad_record_mac" alert MUST be generated. <del> An AEAD cipher MUST NOT produce an expansion of greater than 256 bytes.  An endpoint that receives a record that is larger than 2^14 + 256 octets MUST generate a fatal "record_overflow" alert. </del> <ins> An AEAD cipher MUST NOT produce an expansion of greater than 255 bytes.  An endpoint that receives a record from its peer with TLSCipherText.length larger than 2^14 + 256 octets MUST generate a fatal "record_overflow" alert.  This limit is derived from the maximum TLSPlaintext length of 2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets. </ins> <del> As a special case, we define the NULL_NULL AEAD cipher which is simply the identity operation and thus provides no security.  This cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL cipher suite. </del> <ins> TODO: explain how TLS_NULL_WITH_NULL_NULL is not actually a cipher at all, and that in that state we should send raw TLSPlaintext instead of sending a phony TLSCiphertext </ins> 6.

Discussion:
This pull request has been updated to the current master
Consensus at meeting to merge this PR with updates and with the dummy type byte restored. NAME has action item to actually measure whether we can strip off the now fixed type, record.version bytes.
I've updated this with the expected changes: dummy external ContentType octet is restored, and URL is after fragment.content instead of the other way around (to make it easier to encrypt without having to shuffle buffers).
I agree with davegarrett's suggestion about field naming here, and have supplied a change implementing it.
TLSCiphertext.recordversion provides no useful information, encourages implementations to check it unnecessarily, and wastes two bytes per record. It should be removed entirely. This is effectively dependent on PR or similar changes. Filing this as a specific issue rather than just bringing it up in backwards compatibility discussion. Edited to add: Note that this value is called TLSCiphertext.version in TLS 1.2 and TLSCiphertext.recordversion as of TLS 1.3 draft 06. The TLSPlaintext equivalent of this version field cannot be removed as it is required for backwards compatibility, however it's only used with ClientHello at this point.
Defer pending measurements. Note that this fate shares with removing the cleartext content type
sgtm Amending issue title.
Mozilla is working on measurements.
Change:
1. <del> While WebRTC has been very successful in a wide range of scenarios, its adoption in the broadcasting/streaming industry is lagging behind. </del> The IETF RTCWEB working group standardized JSEP (RFC8829), a mechanism used to control the setup, management, and teardown of a multimedia session.  It also describes how to negotiate media flows

Discussion:
Looks good.
thank you Bernard!
From NAME Section 1 “ While WebRTC has been very successful in a wide range of scenarios, its adoption in the broadcasting/streaming industry is lagging behind.” [BA] I recently saw a survey indicating that WHIP is now the second most implemented ingestion protocol, second only to RTMP. So while this sentence may have been correct at one time, it seems out of date now. Can we delete this sentence? Also, overall Section 1 seems like it could be shortened considerably by highlighting the major points. Here is my suggestion: “ The IETF RTCWEB working group standardized JSEP ([RFC8829]), a mechanism used to control the setup, management, and teardown of a multimedia session. JSEP also describes how to negotiate media flows using the Offer/Answer Model with the Session Description Protocol (SDP) [RFC3264] as well as the formats for data sent over the wire (e.g., media types, codec parameters, and encryption). WebRTC intentionally does not specify a signaling transport protocol at application level. Unfortunately, the lack of a standardized signaling mechanism in WebRTC has been an obstacle to adoption as an ingestion protocol within the broadcast/streaming industry, where a streamlined production pipeline is taken for granted: plug in cables carrying raw media to hardware encoders, then push the encoded media to any streaming service or Content Delivery Network (CDN) ingest using an ingestion protocol. While WebRTC can be integrated with standard signaling protocols like SIP [RFC3261] or XMPP [RFC6120], they are not designed to be used in broadcasting/streaming services and there is no sign of adoption in that industry. RTSP [RFC7826], which is based on RTP, is not compatible with the SDP offer/answer model [RFC3264]. This document therefore proposes a simple protocol for supporting WebRTC as a media ingestion method which: Is easy to implement, Is as easy to use as popular IP-based broadcast protocols Is fully compliant with WebRTC and RTCWEB specs Allows for ingest both in traditional media platforms and in WebRTC end-to-end platforms with the lowest possible latency. Lowers the requirements on both hardware encoders and broadcasting services to support WebRTC. Is usable both in web browsers and in native encoders.”
Change:
private key that signs the delegated credential also implicitly revokes the delegated credential. <del> 6.4. </del> <ins> 7.4. </ins> If a client decides to cache the certificate chain and re-validate it when resuming a connection, the client SHOULD also cache the associated delegated credential and re-validate it. <del> 6.5. </del> <ins> 7.5. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate

Discussion:
From Martin: I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case. Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use. A little bit of a nod in this direction might go a long way to avoiding deployment problems.
Fixed in
Change:
<del> D/TLS IANA Registry Updates </del> <ins> IANA Registry Updates for TLS and DTLS </ins> draft-ietf-tls-iana-registry-updates-latest Abstract <del> This document describes a number of changes to D/TLS IANA registries </del> <ins> This document describes a number of changes to (D)TLS IANA registries </ins> that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the

Discussion:
This changes the title to remove the D/TLS.
It seems that we use D/TLS and (D)TLS interchangeably throughout the document. It should use one of these and the title should probably be something like "IANA Registry Updates for TLS and DTLS"
Change:
The resolution of leaf 1 is the empty list [] <del> The resolution of root node is the list [A, Z, C] </del> <ins> The resolution of top node is the list [A, Z, C] </ins> Every node, regardless of whether the node is blank or populated, has a corresponding _hash_ that summarizes the contents of the subtree

Discussion:
This PR adds two clarifications suggested by NAME Clarifying some antecedents in UpdatePath processing Explaining how the example trees can come about in practice