jiebi/CodeConvo huggingface dataset:
Change:
15.2. <del> [[ OPEN ISSUE: pick DE mailing address.  Maybe mls-des@ or mls-de- pool. ]] </del> <ins> This registry lists identifiers for extensions to the MLS protocol. The extension type field is two bytes wide, so valid extension type values are in the range 0x0000 to 0xffff. Template: Value: The numeric value of the extension type Name: The name of the extension type Message(s): The messages in which the extension may appear, drawn from the following list: KP: KeyPackage messages W: Welcome messages Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. Reference: The document where this extension is defined Initial contents: 15.3. This registry lists identifiers for types of credentials that can be used for authentication in the MLS protocol.  The extension type field is two bytes wide, so valid extension type values are in the range 0x0000 to 0xffff. Template: Value: The numeric value of the credential type Name: The name of the credential type Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. Reference: The document where this extension is defined Initial contents: 15.4. </ins> Specification Required RFC8126 registry requests are registered after <del> a three-week review period on the MLS DEs' mailing list: TBD@ietf.org [1], on the advice of one or more of the MLS DEs.  However, to allow for the allocation of values prior to publication, the MLS DEs may approve registration once they are satisfied that such a specification will be published. </del> <ins> a three-week review period on the MLS DEs' mailing list: mls-reg- review@ietf.org [1], on the advice of one or more of the MLS DEs. However, to allow for the allocation of values prior to publication, the MLS DEs may approve registration once they are satisfied that such a specification will be published. </ins> Registration requests sent to the MLS DEs mailing list for review SHOULD use an appropriate subject (e.g., "Request to register value

Discussion:
This started off just fixing , then grew a bit. Defines an IANA registry for ExtensionType values Defines an IANA registry for CredentialType values Updates the Ciphersuites registry to share formatting with the other two, and to be more explicit about its ties to HPKE algorithms Removes the unnecessary field from ... and as a result removes the definition of (which is used nowhere else)
Now that we have a more robust extension mechanism, we need to have an IANA registry to manage extensions, including: Registry structure Registry policy and (probably) designated experts Reserved vendor space
Change:
Server is responsible for managing the lifecycle of the idempotency key. <del> For each request, server SHOULD </del> <ins> For each request, server </ins> Identify idempotency key from the HTTP "Idempotency-Key" request header field.

Discussion:
This: Gets the editors' draft generated by the template using GitHub actions (was never set up) Fixes up some document metadata Updates the IANA considerations section to fit current practice
looks like this one didn't work as expected, NAME URL
Fixed.
Change:
RFCthis <del> Applications that need to combine representations of potentially several media types into one, e.g., EST-CoAP </del> <ins> Applications that need to combine representations of zero or more different media types into one, e.g., EST-CoAP </ins> N/A

Discussion:
WFM
Oops, I'd missed that. I will change that instance as well.
It should not preclude 0, 1 or 2, therefore: s/several/zero or more/
Maybe just "representations of different media types"?
Change:
overview, which also defines terminology used in this document, including the terms "WebRTC device" and "WebRTC browser". <ins> Terminology for RTP sources is taken fromRFC7656 . </ins> This document focuses on the data transport protocols that are used by conforming implementations, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT

Discussion:
Updated terminology.
On reading the document, I find that the term "media flow" is used where draft-ietf-avtext-rtp-grouping-taxonomy suggests "source stream". Still open what to use instead of "data flow". "Data stream"?
After reconsidering, I added a definition for "flow" instead. Let's see how that scans.
rtcweb-transport: "normal", "below normal", "high" or "very high". tsvwg-rtcweb-qos: “very low”, “low”, “medium”, “high”. WEBRTC-PC: enum RTCPriorityType { "very-low", "low", "medium", "high" }; The majority should win.
Change:
2.2. <ins> An application server MAY include additional claims using public or private names (see Sections 4.2 and 4.3 of RFC7519).  Since the JWT is in a header field, the size of additional claims SHOULD be kept as small as possible. 2.3. </ins> An application server requests the delivery of a push message as described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field

Discussion:
LGTM, thank you! Is the addition required because of the following language in 7519?
Well, that's a good reason, but is the main reason. See the discussion leading up to that.
I read the thread and issue; reading JWT, there was nothing prohibiting providing additional fields (aside from that SHOULD), so I was wondering if specifying this is a normative requirement or a good clarification :-).
If I may, clarification is always good. One should presume that the readers of these specs may not be fully versed in the subtle details of other, reliant specs, so a bit of useful info like this might be very welcome.
As noted in the arguments of , there is a need for an "extra data" field which would be used by the parties using the VAPID claims. This data would contain information useful to the publisher of the claim (e.g. the originating server ID, transaction ID, or other possibly VAPID consumer opaque data). This extra data ("vapid-ext" ?) field would allow consistent, predictable definition rather than a set of 'one-offs' that may be difficult to find or ignored by operators.
Started thread: URL JR requests that we allow the inclusion of extra stuff in a vapid token: URL field which would be used by the parties using the VAPID claims. This data would contain information useful to the publisher of the claim (e.g. the originating server ID, transaction ID, or other possibly VAPID consumer opaque data). This extra data ("vapid-ext" ?) field would allow consistent, predictable definition rather than a set of 'one-offs' that may be difficult to find or ignored by operators. <<< I think that the general idea is fine. Better this than trying to pack the "sub" field with extra stuff. JR, would it suffice to point out that the (or even ) claims can be added to the token? Allowing multiple fields gives the application server a fair bit more flexibility. If that's OK, we should point out that this is possible so that push services don't lose the extra data because they aren't aware that it might exist.
Change:
supported by the underlying transport; and so on.  Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD <del> assign the DSCP Expedited Forwarding RFC3246 PHB. </del> <ins> assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) RFC2597 PHB.  Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding RFC3246 or RFC5865 PHBs. </ins> The application prefers loss to latency but is not interactive. Response time should be optimized at the expense of bandwidth

Discussion:
: added a statement about data arriving before Receive is issued; : removed the confusing sentence; : carried out replacements suggested by NAME
This issue comes from other discussion at the interim of what it means to map to DSCP classes, and proposes to fix two topics. Replace reference OLD: DSCP Less than Best Effort [LE-PHB] PHB NEW: DSCP Less than Best Effort [RFC8622] PHB — Low Latency/Interactive: The current advice is wrong. An endpoint never should be assigning EF without understanding the implication of CAC and policing. OLD: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign the DSCP Expedited Forwarding [RFC3246] PHB; NEW: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) [RFC2597] PHB. Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding [RFC3246] or [RFC5865] PHBs. —
The new text resolve this issue.
I'm not sure I understand this sentence (in sec 8. - Receiving Data): "As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks implied by the Connection's transport parameters." Especially, what's meant by "type of Message"?
Change:
will generally establish state for UDP flows on the first packet sent, and keep state for much shorter idle periods than for TCP. RFC5382 suggests a TCP idle period of at least 124 minutes, though <del> there is not evidence of widespread implementation of this guideline </del> <ins> there is no evidence of widespread implementation of this guideline </ins> in the literature.  Short network timeout for UDP, however, is well- documented.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry can expire after

Discussion:
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
Change:
the maximum message size in bytes that it can receive. As per Section 4.6 of RFC7252, the base value (and the value used <del> when this option is not implemented) is 1152.  A peer that relies on this option being indicated with a certain minimum value will enjoy limited interoperability. </del> <ins> when this option is not implemented) is 1152. </ins> 4.3.3.

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
Change:
4.3. <ins> As Http3Transport sessions are established over HTTP/3, they are identified using the "https" URI scheme RFC7230. </ins> In order to create a new Http3Transport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field MUST be set to "webtransport".  The ":scheme" field MUST be "https".  Both

Discussion:
This defines a new URL scheme for QuicTransport, and clarifies the use of "https" for Http3Transport.
Change:
For all other requests, there MUST be a "kid" field.  This field must contain the account URI received by POSTing to the new-reg resource. <del> Note that authentication via signed POST implies that GET requests are not authenticated.  Servers MUST NOT respond to GET requests for resources that might be considered sensitive. </del> <ins> Note that authentication via signed JWS request bodies implies that GET requests are not authenticated.  Servers MUST NOT respond to GET requests for resources that might be considered sensitive. </ins> If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error with status

Discussion:
Several places talked about account key pairs as being the primary notion of an account, while the account is now primary and has a public key associated with it. Updated to clarify that. Clarified that the account request can contain more than just contact information. Fixed the order of operations in protocol summary to reflect new-order flow.
Change:
4.3. <del> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. "Capsule-Protocol" is an Item Structured Header (see STRUCTURED- FIELDS.  Its value MUST be a Boolean.  Its ABNF is: </del> <ins> This document defines the "Capsule-Protocol" header field.  It is an Item Structured Header RFC8941; its value MUST be a Boolean.  Its ABNF is: </ins> Endpoints indicate that the Capsule Protocol is in use on the data stream by sending the Capsule-Protocol header field with a value of

Discussion:
The HTTP WG is working on a style guide, see URL In line with the style, the reference to structured fields is updated in because it's less contentious. What remains here is probably more so. First, move the consideration for intermediaries to the bottom of the section. It doesn't seem a leading item to me. Then we start the section with a focus on defining the field itself. The ABNF is probably the bit we'll disagree with. It seems in trying to be specific on the Item type, you've written out the the subcomponents of the ABNF. This is something that is being discussed in the HTTP WG list. Personally I don't like being overly specific in the ABNF because it could be misconstrued as something that is SF-like but not really SF. As far as a generic SF parser goes, it will only validate that the thing is an Item and it will be up to higher layers to apply additional constraints on that. Parameters can always appear with an Item on the wire, whether an application allows that or not is a different matter. Restating ABNF makes this topic more thorny.
Change:
Limited RTT measurement is possible by passive observation of QUIC traffic; see sec-rtt.  No passive measurement of loss is possible with the present wire image.  Limited observation of upstream <del> congestion may be possible via the observation of CE markings on ECN- enabled QUIC traffic. </del> <ins> congestion may be possible via the observation of CE markings in the IP header RFC3168 on ECN-enabled QUIC traffic. </ins> On-path devices can also make measurements of RTT, loss and other performance metrics when information is carried in an additional

Discussion:
URL, clarify that the CE marking is observed at IP packet header and also provide a ref to CE marking
Change:
9. <del> This document has no actions for IANA. </del> <ins> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in clusters. A server that rolls out a new version of QUIC can do so in three stages.  Each stage is completed across all server instances before moving to the next stage. In the first stage of deployment, all server instances start accepting new connections with the new version.  The new version can be enabled progressively across a deployment, which allows for selective testing.  This is especially useful when the new version is compatible with an old version, because the new version is more likely to be used. While enabling the new version, servers do not advertise the new version in any Version Negotiation packets they send.  This prevents clients that receive a Version Negotiation packet from attempting to connect to server instances that might not have the new version enabled. During the initial deployment, some clients will have received Version Negotiation packets that indicate that the server does not support the new version.  Other clients might have successfully connected with the new version and so will believe that the server supports the new version.  Therefore, servers need to allow for this ambiguity when validating the negotiated version. The second stage of deployment commences once all server instances are able accept new connections with the new version.  At this point, all servers can start sending the new version in Version Negotiation packets. During the second stage, the server still allows for the possibility that some clients believe the new version to be available and some do not.  This state will persist only for as long as any Version Negotiation packets take to be transmitted and responded to.  So the third stage can follow after a relatively short delay. The third stage completes the process by enabling validation of the negotiation version as though the new version were disabled. The process for disabling an old version or rolling back the introduction of a new version uses the same process in reverse. Servers disable validation of the old version, stop sending the old version in Version Negotiation packets, then the old version is no longer accepted. </ins> 10. <ins> This document has no actions for IANA. 11. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for applications using QUIC, as well.

Discussion:
NAME should probably double-check my work here. This assumes that we take the compatible version upgrade stuff, but if we don't, there's only one sentence to remove. I've tried to keep it abstract enough that the details won't matter.
LGTM. Thank you for writing it down!
Moving this from quicwg/base-drafts to here.
NAME NAME can one of you maybe provide some text?
is probably exactly what needs to be said for this issue.
lgtm
Change:
12. <del> This document has no actions for IANA. </del> <ins> This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations. </ins> 13.

Discussion:
Both documents provide limited guidance on use of ports, however, there was an open question if the applicability statement should maybe say more and e.g. also talk about ALPN.
pending consensus on use of ALPN in -transport
We already have consensus to require ALPN. Unless you meant to refer to URL In that case, yes, you might want to explain how this works for HTTP/3 specifically. That is, the HTTP/3 ALPN refers to QUICv1. For now. We have apparently reserved the right to revise that when we define QUICv2. If you start to explain the controversial aspects of this (does ALPN refer to the layer or the stack as a whole) then you will soon find that you don't have any concrete answers.
Yep, I meant quicwg/base-drafts. This document should provide some advice to application mappings other than HTTP on how/whether to use ALPN, but that advice really will depend on the larger discussion of what ALPN means (is is app-only, a stack designator, or something in between). Having that discussion in this draft is probably not the right thing to do, so holding this issue open until it converges in TLS/HTTP/QUIC.
Probably it would be good to have a more general section on service discovery and point to the HTTP/3 doc as one example.
Create a new section in applicability, and reference the -http draft section 3.1 as an example.
Change:
1. There are cases where deploying FEC coding improves the quality of <del> the transmission.  As an example, when a server transmits data to a client, it may take time for the server to detect tail losses (i.e. tail loss can refer to losses at the tail end of transactions).  This would impact the experience of applications using short flows. Another example are networks where non-congestion losses are persistent and prevent a sender from exploiting the link capacity. </del> <ins> the transmission.  As an example, it may take time for the sender to detect tail losses (i.e. tail loss can refer to losses at the tail end of transactions).  This would impact the experience of applications using short flows.  Another example are networks where non-congestion losses are persistent and prevent a sender from exploiting the link capacity. </ins> Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  RFC5681 defines TCP as a

Discussion:
I propose some rewording and talk about sender and receiver instead of server and client. The sender is not always the server and it could be confusing to assume the sender as being a server (e.g. in ssh it is the inverse). Let me know if you disagree on this.
Au contraire, I disliked the client-server thing from the beginning and thought we should move it to sender-receiver some day! So thanks a LOT for doing this!
LGTM, thanks for this!