jiebi/CodeConvo huggingface dataset:
Code change:
I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments

Related discussion:
text: Within the same Group, and the same priority level, Objects with a lower Object Id are always sent before objects with a higher Object <del> Id, regardless of the specified Group Order.  If the priority varies within a Group, higher priority Objects are sent before lower priority Objects. </del> <ins> Id, regardless of the specified Group Order.  If the group contains more than one Peep and the priority varies between these Peeps, higher priority Peeps are sent before lower priority Peeps, and Objects in peeps are sent in increasing Object Id order. </ins> The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and instead an UNSUBSCRIBE and SUBSCRIBE can be used.
Code change:
I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments

Related discussion:
text: priority for the Object priorities. Object Forwarding Preference: An enumeration indicating how a <del> publisher sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object Forwarding Preference", described below. </del> <ins> publisher sends an object.  The preferences are Track, Peep, and Datagram.  An Object MUST be sent according to its "Object Forwarding Preference", described below. Peep ID: The object is a member of the indicated peep ID (model- peep) within the group.  This field is omitted if the Object Forwarding Preference is Track or Datagram. </ins> Object Status: As enumeration used to indicate missing objects or mark the end of a group or track.  See object-status below.
Code change:
I have foregone any premature optimization of the encodings here. Asking NAME to take a first look.
How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.
I think a Stream FIN would be sufficient.
How am I supposed to know when to send a FIN?
The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.
Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.
How is this represented in the cache? Are FINs guaranteed to be always at the same position? One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.
Good point, I've added an end of Peep object.
OK, I believe I've fully addressed all comments except for those I've left unresolved. NAME NAME If you are satisfied with my response, please resolve the comment.
No normative language, summarize what streams are.
NAME wants to make a proposal, wait for that
For bikesheading on the name, I make these two proposals: "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".
I have made all changes I know to do. I am awaiting NAME making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.
Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!
Block and Stream work for me. I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.
One more name suggestion : SubGroup
Merging with the understanding that we'll continue to discuss how prioritization should work.
Individual Comments

Related discussion:
text: less than a previously sent Object ID within a given group in that stream. <del> 7.5. </del> <ins> 7.4. </ins> Sending a track on one stream: <del> Sending a group on one stream, with a unordered object in the group appearing on its own stream. </del> <ins> Sending a peep on one stream: </ins> 8.
Code change:
This language exists in current draft and refers to an old scheme in which MOQT registered the streaming formats and had a scheme in which the leading varint of the catalog defined the format. This has been superseded by an externalized catalog format and this TODO should be removed. The IANA table for MOQ streaming formats should be managed instead by the Catalog draft, which references those entries.

Related discussion:
text: Message types TODO: register the URI scheme and the ALPN <del> TODO: the MOQT spec should establish the IANA registration table for MoQ Streaming Formats.  Each MoQ streaming format can then register its type in that table.  The MoQ Streaming Format type MUST be carried as the leading varint in catalog track objects. </del>
Code change:
As I observed in this comment: URL, the missing group status seems equivalent to "End of Group" with ObjectId of 0. Additionally, there is no obvious value for ObjectId in Objects with a status of "Group Missing".
makes sense to me

Related discussion:
text: object does not exist at any publisher and it will not be published in the future.  This SHOULD be cached. <del> 0x2 := Indicates Group does not exist.  Indicates that objects with this GroupID do not exist at any publisher and they will not be published in the future.  This SHOULD be cached. </del> 0x3 := Indicates end of Group.  ObjectId is one greater that the largest object produced in the group identified by the GroupID. <del> This is sent right after the last object in the group.  This SHOULD be cached. </del> <ins> This is sent right after the last object in the group.  If the ObjectID is 0, it indicates there are no Objects in this Group. This SHOULD be cached. </ins> 0x4 := Indicates end of Track and Group.  GroupID is one greater than the largest group produced in this track and the ObjectId is
Code change:
It's meant to be sent by the subscriber, indicating that the announce is no longer accepted. The fields should mirror ANNOUNCE_ERROR so the subscriber can indicate stuff like authentication expired, another announce was received, etc.
LG, but I noticed: "If a publisher receives new subscriptions for that namespace after receiving an ANNOUNCECANCEL, it SHOULD close the session as a 'Protocol Violation'." I believe that's racy, because the SUBSCRIBE and ANNOUNCECANCEL can be inflight at the same time? Also, shouldn't it be "after sending an ANNOUNCE_CANCEL", or am I misunderstanding the text?lgtm

Related discussion:
text: Track Namespace: Identifies a track's namespace as defined in (track-name). <ins> Error Code: Identifies an integer error code for canceling the announcement. Reason Phrase: Provides the reason for announcement cancelation. </ins> 6.10. A potential subscriber sends a 'TRACK_STATUS_REQUEST' message on the
Code change:
It's meant to be sent by the subscriber, indicating that the announce is no longer accepted. The fields should mirror ANNOUNCE_ERROR so the subscriber can indicate stuff like authentication expired, another announce was received, etc.
LG, but I noticed: "If a publisher receives new subscriptions for that namespace after receiving an ANNOUNCECANCEL, it SHOULD close the session as a 'Protocol Violation'." I believe that's racy, because the SUBSCRIBE and ANNOUNCECANCEL can be inflight at the same time? Also, shouldn't it be "after sending an ANNOUNCE_CANCEL", or am I misunderstanding the text?lgtm

Related discussion:
text: Announce Error codes <ins> Announce Cancel Reason codes </ins> Message types TODO: register the URI scheme and the ALPN
Code change:
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?

Related discussion:
text: model-group An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved.  An <del> Object can become unavailable, but it's contents MUST NOT change over </del> <ins> Object can become unavailable, but its contents MUST NOT change over </ins> time. Objects are comprised of two parts: metadata and a payload.  The
Code change:
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?

Related discussion:
text: more than one Peep and the priority varies between these Peeps, higher priority Peeps are sent before lower priority Peeps.  If the specified priority of two Peeps in a Group are equal, the lower Peep <del> ID has priority.  Within a Peep, Objects MUST bs sent in increasing </del> <ins> ID has priority.  Within a Peep, Objects MUST be sent in increasing </ins> Object ID order. The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and
Code change:
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?

Related discussion:
text: 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
Code change:
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?

Related discussion:
text: application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar. <ins> When a relay receives an incoming SUBSCRIBE for a given namespace, for each publisher that has announced that namespace, the relay MUST send a SUBSCRIBE to that publisher unless it already has an active subscription to that publisher for the full track name in the incoming SUBSCRIBE. When a relay receives an incoming ANNOUCE for a given namespace, for each active subscription that matches that namespace, it MUST send a SUBSCRIBE to that publisher that send the ANNOUCE. </ins> OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track
Code change:
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?

Related discussion:
text: 6. MOQT uses a single bidirectional stream to exchange control messages, <del> as defined in session-init.  Every signle message on the control </del> <ins> as defined in session-init.  Every single message on the control </ins> stream is formatted as follows: An endpoint that receives an unknown message type MUST close the