jiebi/CodeConvo huggingface dataset:
Code change:
8.1.  URIs <del> [1] https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing- moq-requirements </del> <ins> [1] https://github.com/fiestajetsam/draft-gruessing-moq-requirements </ins>

Related discussion:
text: This adds a few requirements ripped from my blog post, and cleans out use cases and such.
I have some thoughts about the content of this PR, but let's merge it, and see if my thoughts turn into text :-)
Code change:
4.4. <del> Whenever a new entry is to be added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (maximum size - new entry size), or until the table is empty. </del> <ins> Before a new entry is added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (maximum size - new entry size), or until the table is empty. </ins> If the representation of the added entry references the name of an entry in the dynamic table, the referenced name is cached prior to

Related discussion:
text: had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.
Code change:
does not affect the existing options for extending HTTP, such as defining new methods, status codes, or fields (see HTTP). <del> Extensions are permitted to use new FrameHeader, new SettingValues, or new ErrorCodes.  Registries are established for managing these extension points: iana-frames, iana-settings, and iana-errors. </del> <ins> Extensions are permitted to use new FrameHeader, new SETTINGS, or new ErrorCodes.  Registries are established for managing these extension points: iana-frames, iana-settings, and iana-errors. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames

Related discussion:
text: Which changes to
The new reference is to the frame type (not the settings themselves), so I might have preferred the original, but I don't mind. The section is about more than the frame anyway.
Code change:
The application will be able to navigate from the Physical, L2 or L3 topology to the services that use specific resources.  For example, <del> the application will be able to select the resouce and by navigation </del> <ins> the application will be able to select the resouce and by navigating </ins> the supporting relationship bottom-up come to the service and its nodes, tps and links.

Related discussion:
text: Addressed discussion on the nmop group for THREAD1, THREAD2 and THREAD3 as well as issues 1, 2, 3, 5, 6, 7 + some minor changes. 3 commits
Code change:
In contexts where differing congestion control algorithms are used, it is important to understand whether the proposed congestion control <del> algorithm could result in more harm than previously defined algorithms to flows sharing a common bottleneck.  The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the introduced latency, or an increase in packet loss.  An evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. </del> <ins> algorithm could result in more harm than previous standards-track algorithms (e.g.  RFC5681, RFC9002, RFC9438) to flows sharing a common bottleneck.  The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the introduced latency, or an increase in packet loss.  An evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. </ins> 4.2.1.

Related discussion:
text: …ms..." AFAICT the goal is to consider harm induced relative to the harm induced by Reno/CUBIC. There may be other experimental algorithms that become "defined", which are not intended as a yardstick by which to measure harm.
cc: NAME NAME NAME NAME
Code change:
status code indicates that the has been assigned a new permanent URI and any future references to <del> this resource ought to use one of the enclosed URIs.  Clients with link editing capabilities ought to automatically re-link references to the target URI to one or more of the new references sent by the server, where possible. </del> <ins> this resource ought to use one of the enclosed URIs.  The server is suggesting that a user agent with link-editing capability can permanently replace references to the target URI with one of the new references sent by the server.  However, this suggestion is usually ignored unless the user agent is actively editing references (e.g., engaged in authoring content), the connection is secured, and the origin server is a trusted authority for the content being edited. </ins> The server SHOULD generate a

Related discussion:
text: The current text of "ought to ... where possible" is easy to read as saying "if you have the technical capability, do it". There are, however, some subtleties, such as if you get the 308 response over http-not-s, in which case the question of whether or not to re-link is not so clear-cut. Change from "where possible" to "where appropriate" to hint that there is some logic needed here beyond "blindly accept". (inspired by follow-up discussions from )
I like Roy's version better than mine :) I guess I was too conservative...
I think that begs a follow-on question about when it is appropriate. I would be more comfortable with changing the entire sentence to be The change itself is good, but it needs to be done for 301 as well.
Code change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the following terminology from STRUCTURED-FIELDS to specify syntax and parsing: Dictionary, String, Inner List, Token, and Byte Sequence. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> This document uses the following terminology from Section 3 of STRUCTURED-FIELDS to specify syntax and parsing: Dictionary, String, Inner List, Token, and Byte Sequence. </ins> This document uses the line folding strategies described in FOLDING.

Related discussion:
text: This addresses the reference issues, comments and nits from the AD review (see )
NAME would you mind taking a quick look before I publish a new draft?
(tried using ietf-comments but ran into issues so just tracking manually in one combined issue)... cc NAME Thank you for the work on this document. Almost all my comments are about references. I think a new version is necessary before starting IETF Last Call, to avoid process issues along the way. Francesca The boilerplate is duplicate, please remove the second occurrence. Can you please update the reference to 8941 to draft-ietf-httpbis-sfbis ? That doc is with the RFC Editor so should not be holding this document up. Also, I believe the reference to draft-ietf-httpbis-sfbis should be normative, not informative, since terminology from that doc is used. Alternatively, if you want to keep the ref informative, you can import the part of the terminology that is necessary for this doc. I think that's a uglier solution, so I highly prefer sfbis to be made normative, but won't block on it. [URLPattern] "URL Pattern Standard", March 2024, URL needs to be indicated as Living standard (see RFC 9110 or 9421 for eample of whatwg specs references). Please fix this so that the Fetch spec is properly referenced (normatively is needed, I believe). RFC 8792 should be (informatively) referenced. I agree with Mark's write up, 5861 should really be informative. There is several occurrences of {Origin}, please fix. Please add a reference. It would be good to have an informative reference to 6265 (or even 6265bis). This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: URL [ICT]: URL
Code change:
Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing. <ins> This document obsoletes RFC7540 and RFC8740. </ins> 2. HTTP/2 provides an optimized transport for HTTP semantics.  HTTP/2

Related discussion:
text: The current rules state that you need to include text in abstract and introduction. This will result in redundant entries for the specs with other changes that add 7540 references, but we can sort that out later.
Picking my battles more judiciously (as much as I'd like to fight this one, it's a low reward, high risk situation).
informatively, as they are obsoleted by this spec
Rules are boring. Be a rebel without a pause. Omit that text.
Code change:
within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until the publisher of the track terminates the track with a <del> SUBSCRIBE_DONE (see message-subscribe-done). </del> <ins> SUBSCRIBE_DONE (see message-subscribe-done).  A caching relay saves objects to its cache identified by the object's fulltrackname, group ID and object ID.  Relays MUST be ready to process objects for the same fulltrackname from multiple publishers and the objects received are forwarded to active matching subscribers.  If multiple objects are received with the same fulltrackname, group ID and object ID - a caching Relays MUST drop the received objects as duplicate if there exists already an object with the matching fulltrackame, group ID and object ID, in its cache. </ins> Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it

Related discussion:
text: Many thanks on review and any help of fixing all the small stuff (point me too it, or PR on the PR, anything) much appreciated.
NAME - thanks for review. I think I fixed all the stuff you raised. Can you take another look NAME - handing the baton to you on this one. Thanks you
At interim, to support make before break use-cases, we need to clarify relay behavior when a new announce arrives for existing published.
This came up during discussion of . The current draft is ambiguous whether multiple distinct publishers (not reconnect) can announce the same namespace to a relay. If that is allowed, should SUBSCRIBE messages be sent to all publishers that have announced that namespace? What happens if multiple SUBSCRIBE_OKs come back? Do we need normative text describing how a relay handles all these situations, or is it implementation specific? Some possible error conditions: Two publishers publisher the same track/group/object with different content One publisher skips an object (perhaps due to a delivery timeout) but another publisher sends it ?
I initially added a recommended session migration algorithm in . However it's too prescriptive and non-normative and I removed it. However I do think we should talk about what it takes to gracefully migrate a MoqTransport session, if it's non-obvious and should be in the draft (maybe an appendix), and if we need more mechanisms in the protocol. This recommended algorithm requires servers to not error on a duplicate ANNOUNCE. It also results in an RTT where duplicate OBJECTs will arrive on both sessions, which is not necessarily ideal. Here's the original text before I removed it:
I think it'd be useful to have a PR to look at if you're willing to write one up?
Code change:
identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. <del> When using x509, Support for "x5t" is mandatory to implement. </del> <ins> When using x.509 certificates, support for "x5t" is REQUIRED to implement. </ins> Support for "kid" in the protected header and "x5chain" in the <del> unprotected heaer is optional. </del> <ins> unprotected header is OPTIONAL to implement. </ins> When "x5t" is present, "iss" MUST be a string with a value between 1 and 8192 characters in length that fits the regular expression of a

Related discussion:
text: fiddled with the language that intended to be normative and made it normative languageLGTM
Code change:
validation first because it does not always require a conversion into identity encoding. <del> There is a chance that a user agent supporting both mechanisms may find one validates successfully while the other fails.  This document specifies no requirements or guidance for user agents that experience such cases. </del> <ins> A user agent supporting both mechanisms: - can legitimately ignore "Digest" when using SRI, because digest specifies that "a recipient MAY ignore any or all of the representation-data-digests"; - enforce both "Digest" and SRI: in this case it can be useful to provide enough information to identify whether the mismatch happened at the "Digest" or the SRI level. </ins> 10.

Related discussion:
text: clarifies that you can always ignore you can ignore when using SRI if you validate both, it is nice to provide useful errors
Me neither, but this comes from RFC3230.
Well. This is a standards track doc developed in an IETF WG. If we want to change things, we can.
"There is a chance that a user agent supporting both mechanisms may find one validates successfully while the other fails. This document specifies no requirements or guidance for user agents that experience such cases." This makes it sound almost as if it could be ok to ignore an error on one level if there's no error on the other level. I think the spec should say that a user agent supporting both mechanisms must implement all requirements of both specs, no matter what.
Thanks Julian. I agree and will make a PR to tighten up the language.
NAME should we really specify what a SRI implementor should do? RFC3230 explicitly states that URL and we are not changing this.
That doesn't seem to be producing a list in the actual Internet Draft; see URL - maybe an indentation problem.
Code change:
6.6. <ins> A subscriber issues a "UNSUBSCRIBE" message to a publisher indicating it is no longer interested in receiving media for the specified track. The format of "UNSUBSCRIBE" is as follows: Full Track Name: Identifies the track as defined in (track-name). 6.7. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is

Related discussion:
text: Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Code change:
6.6. <ins> A subscriber issues a "UNSUBSCRIBE" message to a publisher indicating it is no longer interested in receiving media for the specified track. The format of "UNSUBSCRIBE" is as follows: Full Track Name: Identifies the track as defined in (track-name). 6.7. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is

Related discussion:
text: Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.
Code change:
Track ID: The track identifier as declared in CATALOG (message- catalog). <del> Object ID: A unique identifier for each object within the track. </del> <ins> Group Sequence : An integer always starts at 0 and increases sequentially at the original media publisher.  Group sequences are scoped under a Track. Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group. </ins> Object Delivery Order: An integer indicating the object delivery order (delivery-order).

Related discussion:
text: Merging based on in-person discussions.
You merged a litttttle early. The wire format is good, but the accompanying text could use some tweaks. For example, it's not specified when the object sequence number should be incremented. It must be done on every independently decodable OBJECT. I'll make another PR.
Code change:
Track ID: The track identifier as declared in CATALOG (message- catalog). <del> Object ID: A unique identifier for each object within the track. </del> <ins> Group Sequence : An integer always starts at 0 and increases sequentially at the original media publisher.  Group sequences are scoped under a Track. Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group. </ins> Object Delivery Order: An integer indicating the object delivery order (delivery-order).

Related discussion:
text: This is a PR to propose changes in the data model PR. Largely work in progress, but I wanted to first propose an organization.
The introductory text seems clear to me. I have questions about what it means for an object to be 'atomic' - since it can necessarily be larger than an MTU it might not get delivered. It can be repaired of course, but what are the consequences to other objects in the group or track if the object never completely arrives? Are there restrictions on receivers attempting to use partial objects? This reader is excited to read the next chapter :D
NAME The main consequence of "atomic" is that it is way better to send one complete object than two incomplete objects. That should very much guide scheduling of transmissions at relays. The other consequence is that if publisher can split a big blob of data into several objects that can be processed independently, they should. For example, instead of sending "the entire GOB as an object", they would get better results sending the GOB as a series of objects, with each object boundary becoming a proper "cut mark". And yes, I have to develop the text. I checked in a partial PR to Suhas' PR, mostly to test my editing chain...
thanks Christian for detailed text. I will merge it into my branch and do an updated version based on this.
Code change:
A <del> frame can alter the initial flow control window size for all current streams.  When the value of </del> <ins> frame can alter the initial flow control window size for all streams in the "open" or "half closed (remote)" state.  When the value of </ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and

Related discussion:
text: Two issues were raised about the use of the words "existing" and "current" to refer to streams. These were a little squishy, so I tightened the language a little. The text no longer uses either word to refer to streams, instead using stream states to describe where the relevant text applies and favouring "identified" as a fallback.
uses some under specified termonlogy: For example is for a PRIORITY frame which can be sent/received in the any state the same as in the following contexts: Can be translated to the stream's state? For example does it roughly mean ? If so then the usage in the PRIORITY frame section is a bit more confusing because a PRIORITY frame could be the first valid frame sent/received for a stream.
NAME - Thanks for the clarification!
NAME - I do have a question regarding your clarifications to the SETTING frame (specifically the SETTINGSINITIALWINDOWSIZE portion). It seems a bit confusing if a PRIORITY frame has been exchanged on an IDLE stream for the SETTINGSINITIALWINDOWSIZE not to apply to it. Consider the following example: 1) Stream is in the state (no frames exchanged) 2) A PRIORITY frame for stream is received. 3) A SETTINGS frame is received to update SETTINGSINITIALWINDOW_SIZE. ... 4) Stream transitions into the state. Is seems a bit counter intuitive that stream 's window will be the window size prior to step 3. Just imagine there are many more SETTINGS frames exchanged (and other events) before step URL stream 's window will be even more difficult to understand how it got to where it is.
That's a fair point. The current text is: From this, you might infer that a reserved or idle stream isn't affected. Implicit in here is that you don't actually have an active flow control window until streams are in those states. There is no sense in performing any accounting until you are actually sending, right? But then, it's only accounting and that 32-bit number might be allocated and used in some implementations. So, I think that this can be clarified, rather than rely on people only accounting in those states, the text might be better saying: Does that make more sense?
This does make more sense. On a related URL is the rational to prohibit WINDOWUPDATES on the IDLE streams when PRIORITY frames have been exchanged?