jiebi/TextFlow huggingface dataset:
Original text:
of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the SUBSCRIBE_ERROR message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given <del> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. </del>  For successful subscriptions, the publisher maintains a list of subscribers for each track.  Each new OBJECT belonging to the track

Reviewer comments:
This is a bit different from HTTP, but having at least one SUBSCRIBE_OK succeed ensures the track exists in some sense, as well as allowing a relay to populate the Group Order field. This is intended as a clarification, but it adds normative language.
LGTM

Revised text:
of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the SUBSCRIBE_ERROR message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given  <ins> SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR.  If a relay does not already have a subscription for the track, or if the subscription does not cover all the requested Objects, it will need to make an upstream subscription.  The relay SHOULD NOT return a SUBCRIBE_OK until at least one SUBSCRIBE_OK has been received for the track, to ensure the Group Order is correct. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each track.  Each new OBJECT belonging to the track
Original text:
Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription <del> aggregation allows relays to make only a single forward subscription for the track.  The published content received from the forward </del>  subscription request is cached and shared among the pending subscribers.

Reviewer comments:
This is a bit different from HTTP, but having at least one SUBSCRIBE_OK succeed ensures the track exists in some sense, as well as allowing a relay to populate the Group Order field. This is intended as a clarification, but it adds normative language.
LGTM

Revised text:
Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription  <ins> aggregation allows relays to make only a single upstream subscription for the track.  The published content received from the upstream </ins> subscription request is cached and shared among the pending subscribers.
Original text:
When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the <del> "Object Send Order" specified in the stream header. </del>  All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".

Reviewer comments:
There are some obsolete references to Object Send Order, and part of the STREAMHEADERTRACK description seems to have slipped below the header for the following section.
Thanks for fixing these .. LGTM

Revised text:
When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the  <ins> "Publisher Priority" specified in the stream header. </ins> All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".
Original text:
When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID". <del> All objects on the stream have the "Object Send Order" specified in </del>  the stream header. All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group". To send an Object with "Object Forwarding Preference" = "Group", find <del> the open stream that is associated with the subscription, "Group ID" and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </del>  The Object Status field is only sent if the Object Payload Length is zero.

Reviewer comments:
There are some obsolete references to Object Send Order, and part of the STREAMHEADERTRACK description seems to have slipped below the header for the following section.
Thanks for fixing these .. LGTM

Revised text:
When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID".  <ins> All objects on the stream have the "Publisher Priority" specified in </ins> the stream header. All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group". To send an Object with "Object Forwarding Preference" = "Group", find  <ins> the open stream that is associated with the subscription and "Group ID", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. </ins> The Object Status field is only sent if the Object Payload Length is zero.
Original text:
specify the canonicalization into the bytes in the Track Namespace or Track Name such that exact comparison works. <del> 2.3.2. </del>  Each track MAY have one or more associated connection URLs specifying network hosts through which a track may be accessed.  The syntax of

Reviewer comments:
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

Revised text:
specify the canonicalization into the bytes in the Track Namespace or Track Name such that exact comparison works.  <ins> 2.4.2. </ins> Each track MAY have one or more associated connection URLs specifying network hosts through which a track may be accessed.  The syntax of
Original text:
priority in every stream or datagram header.  As such, the subscriber's priority is a property of the subscription and the original publisher's priority is a property of the Track and the <del> Objects it contains.  In both cases, a lower value indicates a higher </del>  priority, with 0 being the highest priority. The Subscriber Priority is considered first when selecting a

Reviewer comments:
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

Revised text:
priority in every stream or datagram header.  As such, the subscriber's priority is a property of the subscription and the original publisher's priority is a property of the Track and the  <ins> Peeps it contains.  In both cases, a lower value indicates a higher </ins> priority, with 0 being the highest priority. The Subscriber Priority is considered first when selecting a
Original 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>  The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and instead an UNSUBSCRIBE and SUBSCRIBE can be used.

Reviewer comments:
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

Revised 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  <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.
Original text:
less than a previously sent Object ID within a given group in that stream. <del> 7.5. </del>  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>  8.

Reviewer comments:
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

Revised text:
less than a previously sent Object ID within a given group in that stream.  <ins> 7.4. </ins> Sending a track on one stream:  <ins> Sending a peep on one stream: </ins> 8.
Original 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>

Reviewer comments:
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.

Revised text:
Message types TODO: register the URI scheme and the ALPN
Original 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>  0x4 := Indicates end of Track and Group.  GroupID is one greater than the largest group produced in this track and the ObjectId is

Reviewer comments:
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

Revised text:
object does not exist at any publisher and it will not be published in the future.  This SHOULD be cached.  0x3 := Indicates end of Group.  ObjectId is one greater that the largest object produced in the group identified by the GroupID.  <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
Original text:
Track Namespace: Identifies a track's namespace as defined in (track-name).  6.10. A potential subscriber sends a 'TRACK_STATUS_REQUEST' message on the

Reviewer comments:
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

Revised 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
Original text:
Announce Error codes  Message types TODO: register the URI scheme and the ALPN

Reviewer comments:
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

Revised text:
Announce Error codes <ins> Announce Cancel Reason codes </ins> Message types TODO: register the URI scheme and the ALPN
Original 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>  time. Objects are comprised of two parts: metadata and a payload.  The

Reviewer comments:
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?

Revised 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  <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