jiebi/CodeConvo huggingface dataset:
Code change:
object are still delivered in order; this send order only applies to the ordering between objects. <del> A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (priority-congestion) such that streams are transmitted in send order. </del> <ins> A sender MUST send each object over a dedicated stream.  The library should support prioritization (priority-congestion) such that streams are transmitted in send order. </ins> A receiver MUST NOT assume that objects will be received in send order, for the following reasons:

Related discussion:
text: Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.
Code change:
value, and a trailer section that is terminated by a zero value. Response messages that contain informational status codes result in a <del> different structure; see informational. </del> <ins> different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </ins> Indeterminate-length messages can be truncated in a similar way as known-length messages.  Truncation occurs after the control data, or

Related discussion:
text: The diagram resulted in a few double-takes that might be helped by a little bit of a note pointing this out.
I suspect that requests do not carry the Known-Length Informational Response field (otherwise how do you know how many of them there are?) but that should be spelled out explicitly. I'd suggest creating a different diagram for known-length request vs known-length responses to make this easier to reason about, and same for indeterminate length
I think the optionality is supposed to be indicated by the three trailing dots . I admit to doing a double-take on this during my initial review, similar to David's question. It's optional for a server, sure, but it's never optional for a request just wrong. I agree that separate diagrams would help, at the minor cost of some page space.
Code change:
The "min-append-size" key specifies a minimum size counted in bytes for the request content in a single upload append request <del> (upload-appending).  The server MAY reject requests below this limit and a client SHOULD NOT send smaller upload append requests. The value is an Integer. </del> <ins> (upload-appending) that does not complete the upload by setting the "Upload-Complete: ?1" field.  The server MAY reject non- completing requests below this limit and a client SHOULD NOT send smaller non-completing upload append requests.  A server MUST NOT reject an upload append request due to smaller size if the request includes the "Upload-Complete: ?1" field.  The value is an Integer. </ins> The "expires" key specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response by

Related discussion:
text: This PR clarifies a few things around the Upload-Limit field from : The last upload append request may now be smaller than the minimum append size specified in . For example, if a 510 MB upload is split into 100 MB requests, the last request can just be 10 MB. It clarified how a client can indicate the entire upload length when creating a new upload via the Content-Length header. The PR also mentions that no resumable upload resource may be created if the minimum size is not met, but the server might still accept and process the data (although without offering resumability) The Upload-Limit header is added to informational response in an example
Code change:
The "min-append-size" key specifies a minimum size counted in bytes for the request content in a single upload append request <del> (upload-appending).  The server MAY reject requests below this limit and a client SHOULD NOT send smaller upload append requests. The value is an Integer. </del> <ins> (upload-appending) that does not complete the upload by setting the "Upload-Complete: ?1" field.  The server MAY reject non- completing requests below this limit and a client SHOULD NOT send smaller non-completing upload append requests.  A server MUST NOT reject an upload append request due to smaller size if the request includes the "Upload-Complete: ?1" field.  The value is an Integer. </ins> The "expires" key specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response by

Related discussion:
text: The definition of upload creation requests allows the client to include the entire file, some file data or no data at all. While we provide this flexibility, we don't give guidance on when which approach is best suited. This PR adds this missing piece and explains how an optimistic client can attempt to upload the file in one request and how a careful client uses a separate request for creating the upload. In addition, it also mentions how to transparently upgrade to resumable uploads, which wasn't explained in detail before. Let me know if you have any feedback on this.
Are "Optimistic Upload Creation" and "Upgrading To Resumable Uploads" the exact same way? Maybe the 3rd way could be checking first before uploading?
The way they are described right now they are similar, yes. In theory, an optimistic upload creation can also be used where the client doesn't upload the entire file, but just a large part of it (think 500 MB of a 10 GB file). When upgrading a non-resumable request to a resumable upload, this act of division is not allowed. But I am not sure if we should go into that much detail here. If not, then we can merge these two sections. Upload limits are a good point! With the careful upload, the client also knows the limits before sending the first PATCH request. The optimistic client must be prepared to receive a 104 response with limits that it has to adapt to. We can mention that a careful client may also send an OPTIONS request before hand if it deems that necessary.
I think upload-limit can just be enforced on the server side. If it sends a 104 and a 5xx response, the client would automatically retry. We have deployed a client-side implementation that is not aware of the upload-limit header field.
Thanks for all of your comments! I updated the PR to put the section about upgrading to resumable uploads under the optimistic upload creation since they are similar. I also added a brief mention of Upload-Limit and shortened the text a bit. Let me know if you think the text needs more adjustments.
Just a minor nit. Otherwise I think this is a very good addition and agree with NAME that we should add some text with regards to the .
Code change:
The "min-append-size" key specifies a minimum size counted in bytes for the request content in a single upload append request <del> (upload-appending).  The server MAY reject requests below this limit and a client SHOULD NOT send smaller upload append requests. The value is an Integer. </del> <ins> (upload-appending) that does not complete the upload by setting the "Upload-Complete: ?1" field.  The server MAY reject non- completing requests below this limit and a client SHOULD NOT send smaller non-completing upload append requests.  A server MUST NOT reject an upload append request due to smaller size if the request includes the "Upload-Complete: ?1" field.  The value is an Integer. </ins> The "expires" key specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response by

Related discussion:
text: Proposal for optimistic: The client needs to adapt to the header provided in the intermediate response and fail the request if the file is larger than the maximum allowed size. Proposal for Careful: The client can use the header provided in the to verify that the file is allowed to be uploaded before sending any data.Some editorial suggestions, but one big question: What is the material difference between the first and third strategy? Could these be the same strategy?
Code change:
5.4. <del> The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as </del> <ins> The "Pragma" header field was defined for HTTP/1.0 caches, so that clients could specify a "no-cache" request (as </ins> <del> was not defined until HTTP/1.1).  When the Cache-Control header field is also present and understood in a request, Pragma is ignored. </del> <ins> was not defined until HTTP/1.1). </ins> <del> In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients.  This specification deprecates such extensions to improve interoperability. When the header field is not present in a request, caches MUST consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see cache-request-directive). When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other request directives at HTTP/1.1 or greater caches.  For example: will constrain HTTP/1.1 and greater caches to serve a response no older than 30 seconds, while precluding implementations that do not understand from serving a cached response. </del> <ins> However, support for Cache-Control is now widespread.  As a result, this specification deprecates Pragma. </ins> 5.5.

Related discussion:
text: Note that there's one more reference to pragma remaining, but that will be taken care of by .
... is still hanging around, and even less relevant. We still recommend sending it in certain circumstances; can we drop that?
Specifically: [ ] In Constructing Responses from Caches -- although see [ ] In Pragma, "When sending a no-cache request, a client ought to include both the pragma and cache-control directives" [ ] In Pragma, "When the Cache-Control header field is not present in a request, caches must consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present" Proposal: Change s registration status to "obsoleted" Remove requirements relating to it. Retain text explaining its semantics, and note that it's superseded by .
BTW, I'm comfortable doing this because we're getting rid of requirements on request CC anyway -- see .
I have a few editorial changes to suggest here to make it more readable and remove the trailing note, but it is probably easier to commit this as is and we can tweak it later.
Code change:
10.2. <del> Wherever End-User data is stored, it represents a potential target for an attacker.  This target can be of particularly high value when the data is signed by a trusted authority like an official national </del> <ins> Wherever user data is stored, it represents a potential target for an attacker.  This target can be of particularly high value when the data is signed by a trusted authority like an official national </ins> identity service.  For example, in OpenID Connect OpenID.Core, signed ID Tokens can be stored by Relying Parties.  In the case of SD-JWT, Holders have to store SD-JWTs, and Issuers and Verifiers may decide to do so as well. Not surprisingly, a leak of such data risks revealing private data of <del> End-Users to third parties.  Signed End-User data, the authenticity of which can be easily verified by third parties, further exacerbates the risk.  As discussed in key_binding_security, leaked SD-JWTs may also allow attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys.  Altogether, leaked SD-JWT credentials may have a high monetary value on black markets. </del> <ins> users to third parties.  Signed user data, the authenticity of which can be easily verified by third parties, further exacerbates the risk.  As discussed in key_binding_security, leaked SD-JWTs may also allow attackers to impersonate Holders unless Key Binding is enforced and the attacker does not have access to the Holder's cryptographic keys. </ins> Due to these risks, systems implementing SD-JWT SHOULD be designed to minimize the amount of data that is stored.  All involved parties

Related discussion:
text: should prob add something in history just for posterity - even just a -14 with a "stuff from WGLC part deux"
Code change:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.5. </del> <ins> 5.6. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.6. </del> <ins> 5.7. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.7. </del> <ins> 5.8. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as

Related discussion:
text: Added first-cut of minimum delay text. Intended to
Delay based congestion control protocols are making an assumption that the observed RTT is the sum of a constant "min delay" and a variable queuing delay. This assumption may not be valid on wireless links, as delays vary when the distance between mobile endpoint and base station increases, or when changing transmission condition cause the radios to adopt different modulation and coding strategies. I suspect we also have these "variable delays" in satellite services, especially when using constellations of low orbit satellites. The state of the art is not very good. BBR for example recognizes its dependency on accurate estimate of the min RTT, but has to resort to some kind of periodic reset if measurements of RTT kept over RTT min for 10 seconds -- which is both quite long for some apps, and quite annoying for real time apps suffering a transmission issue every ten seconds. LEDBAT++ does something similar. I think these "variable delays" link are good candidates for "special case" links, to be mentioned in a separate section.
The variable delay part applies to most satellite broadband access using GEO also - not because of propagation usually, but more a result of radio resource sharing. It might well apply to some other technologies that use a shared capacity pool.
Min delay variation strikes me as a bit of a corner case -- perhaps it can be an optional case to evaluate. The other piece is delay variation is not always congestion -- this is IIUC very common in wireless and is part of that mandatory case.
In think this is something like: An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering. In this case, a congestion controller could reduce the sending rate to the point of minimum buffering while still preserving the maximum throughput. An internet Path can also include complex subnetworks where the minimum delay changes over various time scales. This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc. It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes and where a node might then have to buffer data until an assigned transmission opportunity. Variation also results when a higher priority diffserv traffic classic prompts the transmission by a lower class.
Code change:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.5. </del> <ins> 5.6. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.6. </del> <ins> 5.7. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.7. </del> <ins> 5.8. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as

Related discussion:
text: In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.
The delay will also change when the wireless path between two wireless nodes becomes longer, or slower, or shorter, or faster. Or when a wireless router changes the schedule of transmission and starts polling a wireless station more often. or less often. To give an extreme example, suppose a spacecraft flying away from earth at 12,000 km/h. Every hour, the delay will increase by 40 ms.
Sure, however that requirement is very specific to certain systems - my point is that even for fixed cabled and broadband wireless systems, the base delay changes.
I suggest the language "non stationary minimum delay" to encompass all causes that resemble some form of route or path change, explicitly including LEO and mobile motion. It doesn't really cover link layer re transmissions or delays caused by link scheduling algorithms, but these are short term variations that are more likely to be statistically similar to IP queuing delay. I would use the term "hidden queues" to refer to unmanaged queues that (almost) never incur significant backlog but do occasionally cause jitter and generally can not be observed at the IP queuing layer.
NAME will add something in Sec 5 ("Special Cases")
Code change:
. <del> The PUSH_PROMISE frame includes optional padding.  Padding fields and flags are identical to those defined for DATA. </del> <ins> The PUSH_PROMISE frame can include padding.  Padding fields and flags are identical to those defined for DATA. </ins> 6.7.

Related discussion:
text: Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).
Code change:
Informational RFC in 2017 RFC8312 and then as a Proposed Standard in 2023 RFC9438. <del> BBR is developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016.  It was described in an IRTF draft in 2018, and that draft is regularly updated to document the evolving versions of the algorithm BBR-draft. BBR is widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </del> <ins> At the time of writing, BBR is being developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016.  It was described in an IRTF draft in 2018, and that draft has been regularly updated to document the evolving versions of the algorithm BBR-draft.  BBR is currently widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </ins> We cannot say now whether the original authors of RFC5033 expected that developers would be somehow waiting for IETF review before widely deploying a new congestion control algorithm over the Internet, but the examples of Cubic and BBR teach us that deployment <del> of new algorithms is not in fact gated by publication of the </del> <ins> of new algorithms is not in fact gated by the publication of the </ins> algorithm as an RFC. Nevertheless, specifying congestion control algorithms has a number

Related discussion:
text: Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"
Code change:
4.3. <del> Media encoding uses references to improve the compression.  This creates hard and soft dependencies that need to be respected by the transport.  See the appendex for an overview of media encoding (appendix.encoding). An object MAY depend on any number of other objects.  The encoder MUST indicate these dependecies on the wire via the OBJECT header (object). The sender SHOULD NOT use this list of dependencies to determine which object to transmit next.  The sender SHOULD use the delivery order instead, which MUST respect dependencies. The decoder SHOULD process object according to their dependencies. This means buffering a object until the relevent timestamps have been processed in all dependencies.  A decoder MAY drop dependencies at the risk of producing decoding errors and artifacts. 4.4. </del> The decoder will receive multiple objects in parallel and out of order.

Related discussion:
text: It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.