jiebi/CodeConvo huggingface dataset:
Code change:
4. <del> The ALTSVC HTTP/2 frame (Section 4 of HTTP2) advertises the availability of an alternative service to an HTTP/2 client. </del> <ins> The ALTSVC frame advertises the availability of an alternative service to an HTTP/2 or HTTP/3 client. </ins> <del> The ALTSVC frame is a non-critical extension to HTTP/2.  Endpoints that do not support this frame will ignore it (as per the extensibility rules defined in Section 4.1 of HTTP2). </del> <ins> The ALTSVC frame is a separate non-critical extension in each protocol.  Endpoints that do not support this frame will ignore it (as per the extensibility rules defined in Section 4.1 of HTTP2 and Section 4.1 of HTTP3). </ins> <del> An ALTSVC frame from a server to a client on a stream other than stream 0 indicates that the conveyed alternative service is </del> <ins> An ALTSVC frame from a server to a client on a request stream or a push stream indicates that the conveyed alternative service is </ins> associated with the origin of that stream. <del> An ALTSVC frame from a server to a client on stream 0 indicates that </del> <ins> An ALTSVC frame from a server to a client on the control stream (stream 0 in HTTP/2 or a stream of type 0 in HTTP/3) indicates that </ins> the conveyed alternative service is associated with the origin contained in the Origin field of the frame.  An association with an origin that the client does not consider authoritative for the current connection MUST be ignored. <del> The ALTSVC frame type is 0xa (decimal 10). </del> <ins> The ALTSVC frame type is 0xa (decimal 10) in both protocols. </ins> The ALTSVC frame contains the following fields:

Related discussion:
text: The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.
Code change:
1. <del> This document describes the uses cases, requirements, and considerations that should guide the design of the encapsulation of a real-time media transport protocol as a payload in the QUIC protocol (RFC9000), that will be used for live media contribution, syndication, and streaming. Protocol developers have been considering the implications of the QUIC protocol (RFC9000) on media transport for several years, but the initial focus on QUIC in the IETF was to support web applications that used the HTTP/3 protocol I-D.draft-ietf-quic-http.  The completion of the initial versions of the QUIC specifications, and the adoption of I-D.draft-ietf-quic-datagram, have cleared the way for proposals to use QUIC as a media transport.  This document considers a number of proposals for "Media Over QUIC", and analyzes them to understand requirements and considerations. </del> <ins> This document describes the use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", and recommends use cases on live media contribution, syndication, and streaming as the basis for requirements discussions that should guide the design of protocols to satisfy these use cases. </ins> 1.1.

Related discussion:
text: I've been using the phrase "live media", defining it as "media that is actively being produced and consumed". It's not perfect but neither is drawing a numeric latency number in the sand.
NAME - just so that I understand (better) - are you saying that the media is being consumed at (roughly) the rate it's being produced? Any answer is fine, I just want to make sure I know what we're talking about here.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.
Code change:
This document establishes a registry for HTTP/2 error codes.  The "HTTP/2 Error Code" registry manages a 32-bit space.  The "HTTP/2 <del> Error Code" registry operates under the RFC8126. </del> <ins> Error Code" registry operates under the "Expert Review" policy (RFC8126). </ins> Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new

Related discussion:
text: Followup for .
The code for the IANA policies in Section 11.1 looks like this: This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" or "IESG Approval" policies. That would be fine if that rendered as I would expect, as: Instead, it renders this way: That word ordering doesn't make sense. I'm not sure exactly what XML magic would be needed to produce the expected sentence order. Same thing occurs in Sections 11.2-4.
appears to fix only Section 11.1.
Code change:
7. <del> Clients that send HTTP CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data. </del> <ins> In HTTP/1.1, clients that send CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data. </ins> To mitigate vulnerabilities from any clients that do not conform to this requirement, proxy servers MAY close the underlying connection <del> when rejecting an HTTP CONNECT request, without processing any </del> <ins> when rejecting an HTTP/1.1 CONNECT request, without processing any </ins> further data sent to the proxy server on that connection.  Note that this behavior may impair performance, especially when returning a "407 (Proxy Authentication Required)" response.

Related discussion:
text: The current text could be interpreted as applying to other HTTP versions, which is not the intent. cc NAME
Code change:
These bits are concatenated: <del> byte 0 1 2 bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ values |1|1|0|0|1|0|0|1| |0|1|0|0|0|1|0|0| |1|1|1|1|1|0|0|1| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / status 3 0 2 1 1 0 1 0 3 3 2 1 index 3 2 1 0 7 6 5 4 11 10 9 8 _ __/ 0xC9 0x44 0xF9 This results in the byte array: </del> <ins> Resulting in the byte array: </ins> After compression and Base64URL encoding the generated Status List is:

Related discussion:
text: fixes the examples to use constant timestamps in gzip encoding minor changes/fixes to the ascii art / code blocks
Code change:
to a request that has not yet been received, servers SHOULD cache the indication briefly in anticipation of the request. <del> Receipt of more than one unsolicited "USE_CERTIFICATE" frames or an </del> <ins> Receipt of more than one unsolicited "USE_CERTIFICATE" frame or an </ins> unsolicited "USE_CERTIFICATE" frame which is not the first in reference to a given stream MUST be treated as a stream error of type "CERTIFICATE_OVERUSED".

Related discussion:
text: Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.
Code change:
are therefore RECOMMENDED to use different client attestations across different authorization servers. <del> 6. </del> <ins> 7. </ins> TODO <del> 7. </del> <ins> 8. </ins> <del> 7.1. </del> <ins> 8.1. </ins> <del> This section registers the value "client-assertion-type:jwt-key- </del> <ins> This section registers the value "client-assertion-type:jwt-client- </ins> attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. <del> o URN: urn:ietf:params:oauth:client-assertion-type:jwt-key- </del> <ins> o URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- </ins> attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC <del> 7.2. </del> <ins> 8.2. </ins> <del> This section registers the value "attest_key_client_auth" in the IANA </del> <ins> This section registers the value "attest_jwt_client_auth" in the IANA </ins> "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591. <del> o Token Endpoint Authentication Method Name: "attest_key_client_auth" </del> <ins> o Token Endpoint Authentication Method Name: "attest_jwt_client_auth" </ins> o Change Controller: IESG o Specification Document(s): TBC

Related discussion:
text: Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.
Code change:
of the past 30 seconds and replay them in order to "synchronize" the video decoder. <ins> 4.8.6. In all of the applicable use cases defined in overallusecases it may be necessary for consumers to be aware of changes to the source of media being inserted, or be instructed to consume media from a different source.  These may be done for the insertion of advertising or for operational movement of consumers, amongst other reasons. Within the media insertion scenario an existing stream being consumed may change as a result of a different source being spliced which necessitates the decoder being reset as parameters such as video frame rate, image resolution etc may have changed.  For redirection, consumers may be signalled to consume media from a different source which may also require re-initialization of decoder. In both of these scenarios, triggering may occur either through an event provided in the media such as a SCTE-35 marker, or through an external trigger.  Both should be supported. </ins> 4.9. 4.9.1.

Related discussion:
text: I suspect this may require a little bit more thought, but want to sense-check the direction. NAME any feedback you have would be welcome.
NAME NAME thank you both for your feedback, I've rewritten the block again based on your feedback and hope this is a lot more clearer.
MoQ Transport, in combination with a MoQ Streaming Format, needs to support mechanisms to allow ad insertion. This ad insertion: Should be compliant with current IAB and SCTE standards such as SCTE-35, which specifies signals that can be used to identify advertising breaks, advertising content, and programming content. VAST (Video Ad Serving Template) VPAID (Video Player Ad-serving Interface Definition) VMAP (Video Multiple Ad Playlist) Should be able to participate in both server-side and client side ad insertion schemes. The server-side solution may have a mode in which the ad is stitched seamlessly into the primary content and the ad boundaries are indistinguishable to the client. Should be dynamic in nature, allowing for just-in-time decisions to be made for choosing which content to insert. Should allow access to, and compatibility with, a subset of existing ad inventory.
Some of my initials thoughts: To stick to the separation model of "church and state", we should also have agility to support more than SCTE-35/IAB specs in the transport layer Is it required that all streaming formats must support event tracks? Or is the requirement here that just the transport through the catalog enables it? Is there a benefit to describing these requirements more generically - although enabling advertising for live broadcast is clearly the obvious use case having this functionality could be useful for other reasons, such as: In teleconferencing, a presenter switching one (or all) viewer's video to a different source such as the slide show or the presenters camera Falling viewers over to another source when the current one ends e.g Twitch's "raiding"
Given the PR above is merged, I'm closing this noting the above issue on ingest will carry on.
Code change:
4.1. Micro Coding Wizards (MCW) is a small, fictional, software <del> development company providing software solutions to help manage a fleet of electric vehicles (EV) for corporations.  MCW's software solution, MCWManager, is an asset management platform specifically designed to manage electric vehicle fleets.  MCWManager tracks usage, charge level, range, and other important characteristics of each EV in the fleet.  The US Department of the Interior (DOI), a government agency has expressed interest in licensing the MCWManager software to manage a fleet of 20 Electric Vehicles, spread across the Western Region, which includes States west of the Rocky Mountains. </del> <ins> development company providing software solutions for managing fleets of electric vehicles (EV).  MCW's software solution, MCWManager, is an asset management platform specifically designed to manage fleets of electric vehicles.  MCWManager tracks usage, charge level, range, and other important characteristics of each EV in the fleet.  The US Department of the Interior (DOI), a government agency has expressed interest in licensing the MCWManager software to manage a fleet, starting with 20 Electric Vehicles. </ins> MCW has been informed by DOI that their software will be subject to Cybersecurity Executive Order (EO) 14028 recommendations from NIST

Related discussion:
text: A few edits for brevity and conciseness Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution Signed-off-by: Steve Lasker
A VDR is a living document that can be linked to an SBOM document directly, see SPDX V2.3 K.1.9; URL
Is there a proposed change associated with this comment?
Feels like an agreement to the "Differentiate the VDR as incremental information, where the SBOM is static at the time of initial distribution" above?
Thanks NAME I'd suggest the thing we want to capture with SCITT is the continual evolution of information. It's not ok to just update a document as there's no way to know what the state of the document was at a previous date. Example: Jan 1, 2022 - the software was deployed and the VDR showed (all is good). A SCITT claim was submitted, attesting to that current state Jan 10, 2022, the software was deployed, as there were no known issues. A SCITT claim On March 1, 2022 a new vulnerability was discovered that applied to the previous released and deployed software On March 2, 2022, a security auditor might ask: "Why did you deploy the net-monitor:v1` software when there's clearly a security problem? The system has the VDR report from Jan 10, when the software was deployed, to indicate no known vulnerabilities were known at that point. SCITT and the underlying evidence store will need to provide the most recent version of an artifactType, with the ability to query the history as well. Does this give you what you're looking for?
Steve, each new VDR will have a different hash value, so any/all of the VDR artifacts can be checked for trustworthiness, but the "most current VDR should always be registered in SCITT, IMO.
No additional changes are needed, just replace VEX with VDR and we're good to go.
Code change:
Note that this occurs on a response-by-response basis; if no member of the cache's target list is present, valid and non-empty, a cache <del> falls back to other cache control mechanisms as required by HTTP I- D.ietf-httpbis-cache. </del> <ins> falls back to other cache control mechanisms as required by HTTP HTTP-CACHING. </ins> Targeted fields that are not on a cache's target list MUST NOT change that cache's behaviour, and MUST be passed through.

Related discussion:
text: This strengthens the language around Structured Fields so that it's clear they're preferred, and targeted fields are now primarily defined as structured fields. It still leaves using a Cache-Control parser as an option. If we want to go further, we could remove the paragraph starting with 'However,...' and the two bullet points below that.
Reverted in URL for the record
Right now, parsing of targeted Cache-Control is specified like this: The idea here is that while we'd like the interop benefits of SF, we recognise that some -- perhaps many -- implementers will have a strong motivation to reuse their Cache-Control parsers. This seems like it might be the worst of both worlds, in that we now have two possible implementation strategies. Given that there are several now, I wonder whether should reconsider this. E.g., 1) Strengthen the first MAY to a SHOULD, making the field sf-first, or even 2) Require SF, don't allow reuse of CC parsers
Reopening to double-check that we still want to allow CC parsers.
To be clear: the remaining issue (as discussed at the interim) is whether we want to remove the text allowing parsers to be reused for this field.
This seems like the right balance: this is a profile of SF that a CC parser will accept, assuming that a CC parser won't choke on parameterization of "no-cache" or similar.
Code change:
4.1.5. <del> Given a float as input_float, return an ASCII string suitable for use in a HTTP header value. </del> <ins> Given a decimal_number as input_decimal, return an ASCII string suitable for use in a HTTP header value. </ins> Let output be an empty string. <del> If input_float is less than (but not equal to) 0, append "-" to </del> <ins> If input_decimal is less than (but not equal to) 0, append "-" to </ins> output. <del> Append input_float's integer component represented in base 10 </del> <ins> Append input_decimal's integer component represented in base 10 </ins> (using only decimal digits) to output; if it is zero, append "0". <del> Let integer_digits be the number of characters appended in the previous step. If integer_digits is greater than 14, fail serialisation. Let digits_avail be 15 minus integer_digits. Let fractional_digits_avail be the minimum of digits_avail and 6. </del> <ins> If the number of characters appended in the previous step is greater than 12, fail serialisation. </ins> Append "." to output. <del> If input_float's fractional component is 0, append "0" to output. </del> <ins> If input_decimal's fractional component is zero, append "0" to output. </ins> <del> Else if input_float's fractional component has fractional_digits_avail or less digits, append input_float's fractional component represented in base 10 to output. </del> <ins> Else if input_decimal's fractional component has up to three digits, append them represented in base 10 (using only decimal digits) to output. </ins> <del> Else append fractional_digits_avail digits of input_float's fractional component represented in base 10 to output, rounding to the nearest value, or to the even value if it is equidistant. </del> <ins> Otherwise, append the first three digits of input_decimal's fractional component (represented in base 10, using only decimal digits) to output, rounding the final digit to the nearest value, or to the even value if it is equidistant. </ins> Return output.

Related discussion:
text: Time-intervals do not convincingly overcome Gettys 1st rule[1] or Phil Karltons rule[2]. so 12.3 would be fine with me. [1] Do not add new functionality unless an implementor cannot complete a real application without it. [2] The only thing worse than generalizing from one example is generalizing from no examples at all.
These days at least, it's by specification. It's a number in the range 0.000 to 1.000, and all algorithms I know of that use it would be just as well served by an integer from 0 to 1000. So the only reason to include the dot is if we want to backport existing headers as-is. Not backporting existing headers was a justification for some decisions earlier on, so if that's been reversed, should we revisit some of those other decisions?
Although thinking more about it, most of the earlier decisions are sort of OBE, so it's maybe not such a big deal.
PTAL
Code change:
An endpoint might choose to close a connection without sending GOAWAY for misbehaving peers. <ins> A GOAWAY frame might not immediately precede closing of the connection; a receiver of a GOAWAY that has no more use for the connection SHOULD still send a GOAWAY frame before terminating the connection. </ins> The GOAWAY frame does not define any flags. The GOAWAY frame applies to the connection, not a specific stream.

Related discussion:
text: After some sleep, I've read through the section and noticed a few other minor inconsistencies. This alters the structure slightly, as well as replacing the first sentence with a more accurate one. Supercedes . .
+1, thanks
LGTM
Merged by RFC editor.
We are working on a HTTP/2 library and we are a bit confused and we would like to get it right. Is it correct that after a sender sent a frame with some to a receiver, the sender may still open new streams, even with stream identifiers higher than the sent in the frame? That is the frame and the only limit the ability of the receiver? If this is correct, and I believe it is, then I find the following sentence in the first paragraph at confusing. In my opinion it should say something of the like Thanks.
I am also intersted in getting clarity on this topic. It seems what the "spirit" of the is something like: Each endpoint maintains the goaway last stream id from its peer. When a goaway is received then no local streams can be created (i.e. streams can only transition to ), and all local streams with > from the goaway frame are closed (or as the spec says ). Remote streams can still be opened, and to ensure a graceful connection shutdown a goaway frame should be sent in response.
Not quite: Upon receipt of GOAWAY, new streams can be created, but with the following restrictions: those with stream identifiers higher than the will be ignored. Those with stream identifiers lower or equal are subject to the usual risk of loss, but they might be processed. Success is determined by what happens on the stream, of course.
NAME - Can you clarify the following from : This is what lead me to believe that streams can not be "created" after receiving a ?
Hmm. I'd forgotten that. That is in conflict with the graceful shutdown we've specified. I think that we need to take this to the list. This seems like a genuine bug.
Thanks for the quick response NAME Would you prefer to bring the issue to the list?
I'm just trying to formulate something.
hmm I see NAME As a follow up, does the in the GOAWAY have to be the identifier of a stream that actually exists or could it also just be a "random number"?