jiebi/CodeConvo huggingface dataset:
Code change:
This algorithm computes the cross-product of the elements of key- facets. <del> Given key-facets (a list of lists), and key-stub (a string representing a partial key), and possible-keys (a list): </del> <ins> Given key-facets (a list of lists of strings), and key-stub (a list of strings representing a partial key), and possible-keys (a list of lists of strings): </ins> Let values be the first member of key-facets. <del> For each value in values: If key-stub is an empty string, let this-key be a copy of value. </del> <ins> Let remaining-facets be a copy of all of the members of key-facets except the first. </ins> <del> Otherwise: Let this-key be a copy of key-stub. Append a semicolon (";") to this-key. </del> <ins> For each value in values: </ins> <del> Append value to this-key. </del> <ins> Let this-key be a copy of key-stub. </ins> <del> Let remaining-facets be a copy of all of the members of key- facets except the first. </del> <ins> Append value to this-key. </ins> If remaining-facets is empty, append this-key to possible-keys.

Related discussion:
text: I think this also but I might have missed something. Misc changes that aren't actually necessary to use Structured Headers: "variant-item" became "variant-axis". I defined what clients ("caches"?) MUST do when a server violates one of its MUSTs. I removed the (incorrect) definition of available-value in favor of allowing arbitrary . It wasn't clear what excluding characters like was gaining us, and the restriction would have required extra words when parsing the headers. I removed {{gen-variant-key}} entirely and had Compute Possible Keys return a list of lists that could be directly compared against the Structured Header parse of . It would be difficult to keep the old behavior of returning a list of strings without re-adding some restriction on an available-value, for example by requiring that they don't contain spaces. I simplified Compute Possible Keys a bit.
URL shows a Variant-Key of But that's now This also has implications for the URL algorithm, which currently ignores semicolons.
looks like a parameterised list is currently a list of strings, but if is adopted, its syntax will need to be changed, as it doesn't fit into parameterised list particularly well (although I guess it could).
Currently waiting on resolution of .
NAME is closed now. Any hints?
Hi NAME - getting to it. Are you planning on implementing or using?
Code change:
This draft adds entries in three registries. <del> The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in iana- setting.  Four frame types are registered in iana-frame.  Six error codes are registered in iana-errors. </del> <ins> The feature negotiation settings is registered in iana-setting.  Four frame types are registered in iana-frame.  Six error codes are registered in iana-errors. </ins> 7.1. <del> The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 Settings" registry established in RFC7540. SETTINGS_HTTP_CERT_AUTH 0xSETTING-TBD 0 This document. </del> <ins> The SETTINGS_HTTP_CLIENT_CERT_AUTH and SETTINGS_HTTP_SERVER_CERT_AUTH settings are registered in the "HTTP/2 Settings" registry established in RFC7540. </ins> 7.2.

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:
when the peer has received and applied the changed parameter values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the <del> updated settings as soon as possible upon receipt. </del> <ins> updated settings as soon as possible upon receipt.  SETTINGS frames are acknowledged in the order in which they are received. </ins> The values in the SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values.  Unsupported

Related discussion:
text: For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
Code change:
when the peer has received and applied the changed parameter values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the <del> updated settings as soon as possible upon receipt. </del> <ins> updated settings as soon as possible upon receipt.  SETTINGS frames are acknowledged in the order in which they are received. </ins> The values in the SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values.  Unsupported

Related discussion:
text: This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.
Code change:
Abstract <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, that will be used for live media contribution, syndication, and streaming. </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 discussions that should guide the design of protocols to satisfy these use cases. </ins> Note to Readers

Related discussion:
text: Media over QUIC is just the name of a mailing list and a general area of discussion. In some places, the draft refers to it ambiguously where a read may interpret it as the name of a protocol or working group. Maybe can call out that it is not those things and disambiguate references with "Media over QUIC mailing list" or "Media over QUIC problem space"?
I think the issue (or at least the resolution) is also tied to - the objectionable (or at least the obsolete) text in needs to change, and making the changed text also define all the ways we've used the label "MOQ" seems helpful. Expect a PR that attempts to resolve both.
Streams are equally capable of moving media, though the number of different ways to design a protocol have expanded with the addition of datagrams.
Absolutely. It might be worth mentioning that QUIC datagrams in their current state have caveats. They are congestion controlled, elicit acknowledgements, and these acknowledgements . QUIC datagrams certainly have their benefits, but protocols need to be designed to use them properly. Otherwise SRTP and DTLS might be better options.
This term may imply latency constraints that may not exist in all use cases. Further, I wonder if the framing as 'encapsulation of a media transport protocol as a payload' jives with what Victor mentioned during our call -- that part of what's interesting is using QUIC as a transport protocol.
NAME - two things (one each, for your two excellent points): this draft started out as a survey of what was being described as "Media Over QUIC" last summer (after the IETF 111 side meeting), then lurched downhill to being focused on RTP over QUIC, and then lurched BACK uphill, but not all the way uphill, to focusing on a subset of what's been proposed under the banner of "MOQ". Thanks for helping us spot places in the draft that haven't completed the trek! Agreed about reframing the framing, and if we suck any of the other use cases in - there was a lot of discussion around needing help with gaming for sub-100 ms latencies at the IETF 112 side meeting, so that might happen - the current framing might be even less helpful. Definitely worth fixing. Expect a PR soon.
Code change:
Abstract <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, that will be used for live media contribution, syndication, and streaming. </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 discussions that should guide the design of protocols to satisfy these use cases. </ins> Note to Readers

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:
should decouple the checksum calculation: from the payload body - which may be altered by mechanism like <del> Range Requests or the method (eg.  HEAD); </del> <ins> Range Requests RFC7233 or the method (eg.  HEAD); </ins> and from the message body - which depends on "Transfer-Encoding" and whatever tranformations the intermediaries may apply.

Related discussion:
text: Fixes unused references. Removed reference to FIPS180-4 and opened issue Removed unneeded references Uses required references.
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
[x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \
Fixed in
Code change:
the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. <del> 6.12.3. </del> <ins> 6.14.3. </ins> AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases

Related discussion:
text: Delayed LGTM.
Section 5.1 of the draft says: For the second case above, I think it would be useful to have an explicit signal from the publisher to signal the end of the track. For the third case, the text seems to hint (via a section reference) that if the subscription abruptly terminates with an error, the publisher can send SUBSCRIBE ERROR, but that section says: The draft should clarify if this is allowed following a SUBSCRIBE OK. Also +1 to adding UNSUBSCRIBE ().
+1 we should allow sending a SUBSCRIBE ERROR after a SUBSCRIBE OK.
I was assuming that the catalog change would be the way a track end was indicated then the client would unsubscribe.
As an individual: This seems like a bit of a subtle signal and something more explicit using the Track ID would be preferable for me.
I tend to incline towards Catalog indicating the status the more i think of it. Catalog is source of truth for tracks. Having a catalog update that indicates the following Full Track Name lastobjectid field Also if the catalog is ending, since the producer is going away, then include another optional field finished or something These would be sufficient and a clear way to identify the status end to end.
I think putting the FIN group/sequence in the catalog is clean. It does prohibit relays from cleanly terminating a broadcast early or rewriting group/object sequences, but I think that's fine? However, the wrinkle is that a sender MAY choose to not transmit a group/object. While I don't think this is explicitly stated in the draft, it's a requirement given that relays can only cache data for a finite amount of time. The viewer could get stuck waiting for the FIN group/sequence as signaled in the catalog, even though it is not forthcoming as the relay did not receive the object or already evicted it from the cache.
As an individual: Having an explicit signal outside the catalog will make it easier for relays to clean up track related state. If a publisher is done with a track, they can update the catalog, but it will need to propagate to all subscribers, who in turn need to issue an unsubscribe. Only when all of them unsubscribe (which we still need) can a relay discard the entry in the forwarding table. If the publisher also sends an explicit signal closing off the track, the relay can immediately clean up the state.
We need few things.
Code change:
the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. <del> 6.12.3. </del> <ins> 6.14.3. </ins> AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases

Related discussion:
text: Cease the announcement This is an explicit signal from the publisher that it is no longer interested in sending media for the announced tracks. This is sent to the relay to trigger subscription cancellation downstream and clean up local relay state. Terminate the Subscription On subscribe end signal, each receiving entity will forward downstream and clean up local state. If it is the consumer, it stop media pipeline and so on. Unsubscribe For subscribers to explicitly indicate that they are no longer interested in a given track , they will send I am happy to write up a small PR as proposal if we think the general direction is fine.
What is the difference between Cancel the subscription and Unsubscribe?
Unsubscribe is an explicit action from the subscriber and Cancel is the signal from the publisher. May be we should call it ` instead ? I see cancel can be misleading
Got it. Terminate is better than Cancel.
We already have for the publisher to immediately terminate a subscription with a code/reason, so we could reuse that. However, the problem is when the termination occurs. The end of a broadcast would look like: There's a race, as the can arrive before the last objects due to retransmits or congestion control, severing the subscription early. Ideally we wait for all outstanding objects to get delivered and then terminate the subscription. In QUIC terminology, we need a in addition to our existing . The difficult part is determining which objects are still outstanding.
Do we want to distinguish a normal end of subscription (due to EOF), and an unexpected end (due to, e.g., a downstream server crashing)? We do that normally in QUIC (fin vs reset), so it might make sense to do that here.
Image the case where we have A sending to R sending to B. B subscribes to R. A sends ANNOUNCE to R. R subscribes to A. At this point media is flowing from A to R to B. A temporary looses WIFI connectivity and reconnects over 5G with new IP. A sends an ANNOUNCE to R, R subscribes to the new A and perhaps tries to send an error to original ANNOUNCE and end subscribe but A will not get that as that QUIC connection is gone.
Code change:
the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. <del> 6.12.3. </del> <ins> 6.14.3. </ins> AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases

Related discussion:
text: Once again data is flowing from A to R to B. I think it would be bad if the new ANNOUNCE, or an error on the QUIC connection from A to R caused a termination or error of the subscribe between B and R. I'm think it is better for B to unsubscribe if it is not receiving the media it wold expect.
Having explicit messages reflecting the actions would be my inclination as well. I thought it might be beneficial to explain the role of the above proposed messages with few flow diagrams Here is the happy path flow (it ignores Subscribe_OK and response flows to keep the flow focussed)
Summary thoughts: Want to support disconnection without propagation to all subscribers (ie: If there were two publishers) Need a way to cleanly unsubscribe from a track (UNSUBSCRIBE) - Like STOPSENDING? Need a way to indicate that a relay is no longer the place to subscribe to for a track (ie: UNANNOUNCE) But UNANNOUNCE does not indicate an unsubscription. Need a way to indicate the track is FIN'd and ending, could use the catalog or put in the protocol (or both) Likely want a way to drain a relay, such as an HTTP GOAWAY style functionality. (Could be SUBSCRIBETERMINATE) Timeouts do need to be handled, even if they're not the ideal/clean case. Want to know whether the relay wants to stop publishing or the origin did, so a client can decide whether to re-sub. NOTE: Objects can be dropped, hard to know if they'll ever arrive. Cullen will summarize a proposal. Note that the relay doesn't really need to know about tracks or what its subscribing to. An open issue is how to do FIN, whether it as part of Objects, only the catalog, a separate message, etc.
Rough notes on proposal in the call: The catalog updates and says what the last message in a track is. Catalogs are a way that endpoints can say there will never be more on a track. The annouce has an equivalent un-Annouce message. It changes routing of future subscribes but does not change state of existing subscribes. The entity that send an subscribe and send an un-subscribe The entity that receives a subscribe can send a go-away which will let the entity that sent the subscribe go do something new ( like subscribe to something else ).
Code change:
the selected group when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. <del> 6.12.3. </del> <ins> 6.14.3. </ins> AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases

Related discussion:
text: We might need to figure out what data goes in the go away to given info that the clients enough info to do the right thing. Timeout can happen, and connections disappearing, and we need to sort out what impact that has but that is not the primary way to cause flow of media to change. Update: Key issue here is when the relays see the go away, do they drop the related forwarding state for the subscription, or do they just forward the update to the subscribers and wait for the subscribers to remove the subscription.
NAME NAME thanks for capturing the notes. I will work on set of small PRs to capture some of the items from the summary.
The point I was trying to clarify on the last call was that catalog already has a mechanism for a publisher to communicate to all subscribers that the track it has advertised as being available is no longer available. A clean FIN if you like. We can, as has been pointed out, create a control message which says the same thing. But then we have a weird asymmetry in which a publisher notifies clients of track availability through a catalog update but then uses control messages to do the reverse. For good design with clean encapsulation, we should seek symmetry in operation. We should either use control messages to advertise the availability/unavailability of tracks , or use catalogs, but not a hybrid of both. In my understanding of moq-transport, control messages have utility that is scoped to the current hop. They negotiate the format in which data will be exchanged on that hop and issue commands to subscribe/unsubscribe/announce etc. Those commands have no applicability to any other hops on the distribution chain. A catalog however is a contract between a publishers and all subscribers. Unlike control messages, it holds data that is not interpreted hop-by-hop and is intended for targets that can be many hops away. I think relays should be as simple as possible. In my conception, they should not understand whether tracks are being published or not. Their job is to move objects. Their view of the world is around objects and they do not need to understand what tracks are. While of course we can build all sorts of track intelligence in to relays, I think if we can build a base protocol which is agnostic to tracks, then it will be scalable and robust, and cleverness with tracks can evolve in the streaming formats without affecting deployed networks of relays.
Code change:
This document <del> 10.  References </del> <ins> 12.  References </ins> <del> 10.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/

Related discussion:
text: and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.