jiebi/TextFlow huggingface dataset:
Original 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>  Object ID order. The Group Order cannot be changed via a SUBSCRIBE_UPDATE message, and

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:
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  <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
Original 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>  Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber receives a SUBSCRIBE_ERROR after receiving objects, it

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:
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  <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
Original text:
application.  For example, a SUBSCRIBE namespace=foobar message will be forwarded to the session that sent ANNOUNCE namespace=foobar.  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

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:
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
Original 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>  stream is formatted as follows: An endpoint that receives an unknown message type MUST close 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:
6. MOQT uses a single bidirectional stream to exchange control messages,  <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
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:
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:
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:
SUBSCRIBE_NAMESPACE is not required for a publisher to send ANNOUNCE and UNANNOUNCE messages to a subscriber.  It is useful in applications or relays where subscribers are only interested in or <del> authorized to access a subset of available annoucements. </del>  6.12.

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:
SUBSCRIBE_NAMESPACE is not required for a publisher to send ANNOUNCE and UNANNOUNCE messages to a subscriber.  It is useful in applications or relays where subscribers are only interested in or  <ins> authorized to access a subset of available announcements. </ins> 6.12.
Original text:
Announce Error codes  Message types TODO: register the URI scheme and the ALPN

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:
Announce Error codes <ins> Announce Cancel Reason codes </ins> Message types TODO: register the URI scheme and the ALPN
Original text:
session as a 'Protocol Violation' if it receives a second bidirectional stream. <del> The control stream MUST NOT be abruptly closed at the underlying transport layer.  Doing so results in the session being closed as a 'Protocol Violation'. </del>  3.4.

Reviewer comments:
Sorry for the late response but I dont think this text is quite correct. If you're running MoQ over WebTransport, you're likely to be following the instructions in URL, which states My reading of the current text means that endpoints are likely to blend up treating things as a violation when there is no violation.
Section 3.3 says: "The control stream MUST NOT be abruptly closed at the underlying transport layer. Doing so results in the session being closed as a 'Protocol Violation'." I know we have multiple transports, but it would be good to clarify what an abrupt close is. Presumably any sort of RESET_STREAM, but what happens if there's a FIN? Is this a "clean close" of the session? Does it imply or force a reset of data streams?
LGTM

Revised text:
session as a 'Protocol Violation' if it receives a second bidirectional stream.  <ins> The control stream MUST NOT be closed at the underlying transport layer while the session is active.  Doing so results in the session being closed as a 'Protocol Violation'. </ins> 3.4.
Original text:
time. Objects are comprised of two parts: metadata and a payload.  The <del> metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the Original Publisher and End Subscribers.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del>  2.2.

Reviewer comments:
My understanding is that MoQ is always hop-by-hop encrypted by virtue of working over QUIC or WebTransport, and therefore a "relay" as described in the draft can only inspect Track/Group/Object metadata if it terminates QUIC. The document should clarify the requirements.
I agree with Alan. As a QUIC enthusiast, I guess the current draft implicitly suggests hop-by-hop QUIC termination at relay, e.g., which is necessary to enable cache at relay while having MOQT Message Type and OBJECT metadata as QUIC payload. Yet it is definitely more clarified for readers to explicitly see that information in an early section (e.g., sec 1.1.4).
Given MoQ is over either QUIC or WebTransport, I believe it's impractical to restrict it to only QUIC based transports.
The context of the question is whether one can build an MoQ relay that can view object properties without terminating the TLS session underpinning MoQ or WebTransport (eg an untrusted middlebox).
LG, but given Webtransport is also a substrate MoQ runs over, I think we want to avoid using QUIC connection?LGTM

Revised text:
time. Objects are comprised of two parts: metadata and a payload.  The  <ins> metadata is never encrypted and is always visible to relays (see relays-moq).  The payload portion may be encrypted, in which case it is only visible to the Original Publisher and End Subscribers.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> 2.2.
Original text:
3.5. <del> The transport session can be terminated at any point.  When native </del>  QUIC is used, the session is closed using the CONNECTION_CLOSE frame (QUIC).  When WebTransport is used, the session is closed using the CLOSE_WEBTRANSPORT_SESSION capsule (WebTransport).

Reviewer comments:
My understanding is that MoQ is always hop-by-hop encrypted by virtue of working over QUIC or WebTransport, and therefore a "relay" as described in the draft can only inspect Track/Group/Object metadata if it terminates QUIC. The document should clarify the requirements.
I agree with Alan. As a QUIC enthusiast, I guess the current draft implicitly suggests hop-by-hop QUIC termination at relay, e.g., which is necessary to enable cache at relay while having MOQT Message Type and OBJECT metadata as QUIC payload. Yet it is definitely more clarified for readers to explicitly see that information in an early section (e.g., sec 1.1.4).
Given MoQ is over either QUIC or WebTransport, I believe it's impractical to restrict it to only QUIC based transports.
The context of the question is whether one can build an MoQ relay that can view object properties without terminating the TLS session underpinning MoQ or WebTransport (eg an untrusted middlebox).
LG, but given Webtransport is also a substrate MoQ runs over, I think we want to avoid using QUIC connection?LGTM

Revised text:
3.5.  <ins> The Transport Session can be terminated at any point.  When native </ins> QUIC is used, the session is closed using the CONNECTION_CLOSE frame (QUIC).  When WebTransport is used, the session is closed using the CLOSE_WEBTRANSPORT_SESSION capsule (WebTransport).
Original text:
(CDNs).  Additionally, relays serve as policy enforcement points by validating subscribe and publish requests at the edge of a network.  Relays can cache Objects, but are not required to. 5.1.

Reviewer comments:
My understanding is that MoQ is always hop-by-hop encrypted by virtue of working over QUIC or WebTransport, and therefore a "relay" as described in the draft can only inspect Track/Group/Object metadata if it terminates QUIC. The document should clarify the requirements.
I agree with Alan. As a QUIC enthusiast, I guess the current draft implicitly suggests hop-by-hop QUIC termination at relay, e.g., which is necessary to enable cache at relay while having MOQT Message Type and OBJECT metadata as QUIC payload. Yet it is definitely more clarified for readers to explicitly see that information in an early section (e.g., sec 1.1.4).
Given MoQ is over either QUIC or WebTransport, I believe it's impractical to restrict it to only QUIC based transports.
The context of the question is whether one can build an MoQ relay that can view object properties without terminating the TLS session underpinning MoQ or WebTransport (eg an untrusted middlebox).
LG, but given Webtransport is also a substrate MoQ runs over, I think we want to avoid using QUIC connection?LGTM

Revised text:
(CDNs).  Additionally, relays serve as policy enforcement points by validating subscribe and publish requests at the edge of a network. <ins> Relays are endpoints, which means they terminate Transport Sessions in order to have visibility of MoQ Object metadata. </ins> Relays can cache Objects, but are not required to. 5.1.