jiebi/TextFlow huggingface dataset:
Original text:
object are still delivered in order; this send order only applies to the ordering between objects. <del> A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (priority-congestion) such that streams are transmitted in send order. </del>  A receiver MUST NOT assume that objects will be received in send order, for the following reasons:

Reviewer comments:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Revised text:
object are still delivered in order; this send order only applies to the ordering between objects.  <ins> A sender MUST send each object over a dedicated stream.  The library should support prioritization (priority-congestion) such that streams are transmitted in send order. </ins> A receiver MUST NOT assume that objects will be received in send order, for the following reasons:
Original text:
Packet loss or flow control can delay the send of individual streams. <del> The sender might not support QUIC stream prioritization. </del>  TODO: Refer to Congestion Response and Prioritization Section for further details on various proposals.

Reviewer comments:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Revised text:
Packet loss or flow control can delay the send of individual streams.  <ins> The sender might not support stream prioritization. </ins> TODO: Refer to Congestion Response and Prioritization Section for further details on various proposals.
Original text:
A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.  Packet loss will cause stream data <del> to be buffered in the QUIC library, awaiting in order delivery, which will increase latency over additional hops.  To mitigate this, a relay SHOULD read and write QUIC stream data out of order subject to flow control limits.  See section 2.2 in QUIC. </del>  6. <del> Both unidirectional and bidirectional QUIC streams contain sequences of length-delimited messages. </del>  An endpoint that receives an unknown message type MUST close the connection.

Reviewer comments:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Revised text:
A relay that reads from a stream and writes to stream in order will introduce head-of-line blocking.  Packet loss will cause stream data  <ins> to be buffered in the library, awaiting in order delivery, which will increase latency over additional hops.  To mitigate this, a relay SHOULD read and write stream data out of order subject to flow control limits.  See section 2.2 in QUIC. </ins> 6.  <ins> Both unidirectional and bidirectional streams contain sequences of length-delimited messages. </ins> An endpoint that receives an unknown message type MUST close the connection.
Original text:
Live content requires significant bandwidth and resources.  Failure to set limits will quickly cause resource exhaustion. <del> MOQT uses QUIC flow control to impose resource limits at the network layer.  Endpoints SHOULD set flow control limits based on the anticipated bitrate. </del>  Endpoints MAY impose a MAX STREAM count limit which would restrict the number of concurrent streams which a MOQT Streaming Format could

Reviewer comments:
Given this also runs over WebTransport, it's best to avoid QUIC unless it's specifically referring to the transport.
Though MOQT is optimized for QUIC, it technically can go over WebTransport over HTTP/1 or HTTP/2. There are a number of cases when QUIC is used when it could be something else and in most cases, specifying QUIC is not critical to the design. For example "Consumer: A QUIC endpoint receiving media over the network." Also, the definitions in 1.2 frequently reference terms defined later in the list.
Absolutely. Stream prioritization and congestion control is better with QUIC, and thus can support lower latencies, but MoQ over TCP should still work well enough.
For what its worth, we did did say during chartering that were were not going to focus on solving any of the problems that happen with fallback to TCP. Clearly we are not going to go and brak whatever fallback WebTransport does, but they key thing is this work when then WebTransport is over QUIC, not other cases
I completely agree. This is an editorial point that there are times when 'QUIC' is used when it may not actually be QUIC. In many cases, just removing that word makes the sentence both slightly more accurate and shorter.

Revised text:
Live content requires significant bandwidth and resources.  Failure to set limits will quickly cause resource exhaustion.  <ins> MOQT uses stream limits and flow control to impose resource limits at the network layer.  Endpoints SHOULD set flow control limits based on the anticipated bitrate. </ins> Endpoints MAY impose a MAX STREAM count limit which would restrict the number of concurrent streams which a MOQT Streaming Format could
Original text:
6.2. <del> The "SETUP" message is the first message that is exchanged by the client and the server; it allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called SETUP parameters; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </del>  <del> The wire format of the SETUP message is as follows: </del>  The available versions and SETUP parameters are detailed in the next sections.

Reviewer comments:
Feel free to change the numbers to any ones you prefer.
There's a single SETUP message, but the contents change based on if the endpoint is a server or a client. . This is difficult to implement in type safe languages. I would implement and , sharing the same ID. However, it's then difficult to implement a generic method as it needs to know the expected role to distinguish between the two. I propose a separate and message akin to how TLS has a separate and . Alternatively, implement to reclassify SETUP and OBJECT as control and data stream headers respectively.
Hmm, so this isn't a problem in my code any longer since made SETUP a special message type. We should still figure out if both the client and server SETUP use the same ID, or separate IDs like TLS.
I still like the idea of, if these message are different, they should have different names as it will just be confusing if they do not.
Agreement these should be different message types, just like TLS.
Conveniently, message id=2 is currently not used. I propose ClientSetup = 1 and ServerSetup = 2.
Thinking about this a bit more, do we want to bake in the assumption that the client always speaks first into the protocol? For raw QUIC, typically, the server would have 1-RTT keys first.
I would love to see something like HTTP/3 SETTINGS where both endpoints can send the message in parallel. That requires version negotiation at a lower level in something like ALPN though. The SERVER SETUP would be sent first in native QUIC while the CLIENT SETUP could be sent first with WebTransport (in parallel with CONNECT).
LGTM

Revised text:
6.2.  <ins> The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages exchanged by the client and the server; they allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called SETUP parameters; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </ins>  <ins> The wire format of the SETUP messages is as follows: </ins> The available versions and SETUP parameters are detailed in the next sections.
Original text:
6.1.1.1. <del> The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects in a SUBSCRIBE message.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  The value is of type varint. 6.1.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects in a SUBSCRIBE message.  The "GROUP SEQUENCE" parameter MUST be set to identify the group under which to start delivery.  The publisher MUST start delivering from the beginning of the selected group when this parameter is omitted. The value is of type varint. 6.1.1.3. </del> AUTHORIZATION INFO parameter (key 0x02) identifies a track's authorization information in a SUBSCRIBE or ANNOUNCE message.  This parameter is populated for cases where the authorization is required

Reviewer comments:
This were replaced in Subscribe Locations (hints)
These parameters have been replaced with explicit fields in the SUBSCRIBE message. All that's left (outside of SETUP) is AUTHORIZATIONINFO in SUBSCRIBE and ANNOUNCE. I would just as soon get rid of non-setup parameters entirely and have an "authinfolength" field in the messages which can be zero. At a minimum, we need to eliminate GROUP and OBJECT_SEQUENCE.
+1 I would go even further and make a dedicated AUTH message.
Whoops, those were deleted but must have been re-added in a merge conflict.

Revised text:
6.1.1.1.  AUTHORIZATION INFO parameter (key 0x02) identifies a track's authorization information in a SUBSCRIBE or ANNOUNCE message.  This parameter is populated for cases where the authorization is required
Original text:
Reason Phrase Length: The length in bytes of the reason phrase. <del> Reason Phrase: Provides the reason for subscription error and "Reason Phrase Length" field carries its length. </del>  6.7.

Reviewer comments:
When we added (b) we didn't update this.
SUBSCRIBE_RST as well
and ANNOUNCE_ERROR

Revised text:
Reason Phrase Length: The length in bytes of the reason phrase.  <ins> Reason Phrase: Provides the reason for subscription error. </ins> 6.7.
Original text:
Error Code: Identifies an integer error code for subscription failure. <del> Reason Phrase Length: The length in bytes of the reason phrase. Reason Phrase: Provides the reason for subscription error and "Reason Phrase Length" field carries its length. </del>  Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track.

Reviewer comments:
When we added (b) we didn't update this.
SUBSCRIBE_RST as well
and ANNOUNCE_ERROR

Revised text:
Error Code: Identifies an integer error code for subscription failure.  <ins> Reason Phrase: Provides the reason for subscription error. </ins> Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track.
Original text:
Error Code: Identifies an integer error code for announcement failure. <del> Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. </del>  6.13.

Reviewer comments:
When we added (b) we didn't update this.
SUBSCRIBE_RST as well
and ANNOUNCE_ERROR

Revised text:
Error Code: Identifies an integer error code for announcement failure.  <ins> Reason Phrase: Provides the reason for announcement error. </ins> 6.13.
Original text:
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR. <del> OBJECT message header carry short hop-by-hop Track Id that maps to </del>  the Full Track Name (see message-subscribe-ok).  Relays use the Track ID of an incoming OBJECT message to identify its track and find the active subscribers for that track.  Relays MUST NOT depend on OBJECT

Reviewer comments:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Revised text:
ANNOUNCE MUST send only a single response to a given ANNOUNCE of either ANNOUNCE_OK or ANNOUNCE_ERROR.  <ins> OBJECT message header carry short hop-by-hop Track ID that maps to </ins> the Full Track Name (see message-subscribe-ok).  Relays use the Track ID of an incoming OBJECT message to identify its track and find the active subscribers for that track.  Relays MUST NOT depend on OBJECT
Original text:
specified track, as well as associated metadata required to deliver, cache, and forward it.  There are two subtypes of this message.  When the message type is 0x00, the optional Object Payload Length field is <del> present.  When the message type ix 0x02, the field is not present. </del>  The format of the OBJECT message is as follows: <del> Track ID: The track identifier obtained as part of subscription and/or publish control message exchanges. </del>  Group Sequence : The object is a member of the indicated group model-group within the track.

Reviewer comments:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Revised text:
specified track, as well as associated metadata required to deliver, cache, and forward it.  There are two subtypes of this message.  When the message type is 0x00, the optional Object Payload Length field is  <ins> present.  When the message type is 0x02, the field is not present. </ins> The format of the OBJECT message is as follows:  <ins> Track ID : The compressed full track name obtained as part of subscription and/or publish control message exchanges. </ins> Group Sequence : The object is a member of the indicated group model-group within the track.
Original text:
6.4.2. <del> The format of SUBSCRIBE REQUEST is as follows: </del>  Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name).  StartGroup: The Location of the requested group.  StartGroup's Mode MUST NOT be None.

Reviewer comments:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Revised text:
6.4.2.  <ins> The format of SUBSCRIBE is as follows: </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). <ins> Subscribe ID: Session unique identifier for the subscription. "Subscribe ID" is monotonically increasing variable length integer and it MUST uniquely identify a subscription within a session. "Subscribe ID" is used by subscribers and the publishers to identify a given subscription.  Subscribers specify the "Subscribe ID" and it is included in the corresponding SUBSCRIBE_OK or SUBSCRIBE_ERROR. </ins> StartGroup: The Location of the requested group.  StartGroup's Mode MUST NOT be None.
Original text:
publisher MUST NOT send objects from outside the requested start and end.  6.4.3. 6.5.

Reviewer comments:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Revised text:
publisher MUST NOT send objects from outside the requested start and end. <ins> TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.) </ins> 6.4.3. 6.5.
Original text:
the Full Track Name in the Track ID field of the OBJECT (message- object) message headers of the requested track.  Track IDs are generally shorter than Full Track Names and thus reduce the <del> overhead in OBJECT messages. </del>  Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays

Reviewer comments:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Revised text:
the Full Track Name in the Track ID field of the OBJECT (message- object) message headers of the requested track.  Track IDs are generally shorter than Full Track Names and thus reduce the  <ins> overhead in OBJECT messages Subscribe ID: Subscription Identifer from the incoming subscription request for which this message is the response. </ins> Expires: Time in milliseconds after which the subscription is no longer valid.  A value of 0 indicates that the subscription stays
Original text:
A publisher sends a SUBSCRIBE_ERROR control message in response to a failed SUBSCRIBE. <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del>  Error Code: Identifies an integer error code for subscription failure.

Reviewer comments:
This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.

Revised text:
A publisher sends a SUBSCRIBE_ERROR control message in response to a failed SUBSCRIBE.  <ins> Subscribe ID: Subscription Identifer as defined in message- subscribe-req. </ins> Error Code: Identifies an integer error code for subscription failure.