jiebi/TextFlow huggingface dataset:
Original text:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel.  7. TODO: Expand this section.

Reviewer comments:
This PR adds support for subscribers to issue unsubscribe requests to express its interest in not receiving media for a given track. This reflects discussions from The high level call flow is
Thinking about it some more, an error code doesn't seem necessary. publisher -> subscriber should have an error code. subscriber -> publisher doesn't need an error code. Even with an error code, it would get lost in the deduplication process.
Individual reviewIt might be useful to have an error code, but I'm not sure. LGTM.We'll need to revisit using track name vs track ID for unsubscribe once we have an answer to , but for now, this LGTM.

Revised text:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.12. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.12.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.12.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  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.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.12.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.
Original text:
Announce Error codes <del> Unsubscribe Error codes </del> Track format numbers Message types

Reviewer comments:
This PR adds support for subscribers to issue unsubscribe requests to express its interest in not receiving media for a given track. This reflects discussions from The high level call flow is
Thinking about it some more, an error code doesn't seem necessary. publisher -> subscriber should have an error code. subscriber -> publisher doesn't need an error code. Even with an error code, it would get lost in the deduplication process.
Individual reviewIt might be useful to have an error code, but I'm not sure. LGTM.We'll need to revisit using track name vs track ID for unsubscribe once we have an answer to , but for now, this LGTM.

Revised text:
Announce Error codes  Track format numbers Message types
Original text:
Track Request Parameters: The parameters are defined in track-req- params. <del> 6.6.1. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. 6.6.1.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  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.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.6.1.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </del> 6.7. The receiver sends an "ANNOUNCE OK" control message to acknowledge

Reviewer comments:
Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review

Revised text:
Track Request Parameters: The parameters are defined in track-req- params.  6.7. The receiver sends an "ANNOUNCE OK" control message to acknowledge
Original text:
6.9.  The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without severing the QUIC connection.  The server can be a producer or a

Reviewer comments:
Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review

Revised text:
6.9. <ins> The publisher sends the "UNANNOUNCE" control message to indicate its intent to stop serving new subscriptions for tracks within the provided Track Namespace. Track Namespace: Identifies a track's namespace as defined in (track-name). 6.10. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without severing the QUIC connection.  The server can be a producer or a
Original text:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel.  7. TODO: Expand this section.

Reviewer comments:
Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review

Revised text:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.11. The Track Request Parameters identify properties of the track requested in either the ANNOUNCE or SUSBCRIBE REQUEST control messages.  The peers MUST close the connection if there are duplicates.  The Parameter Value Length field indicates the length of the Parameter Value. The format of "Track Request Parameter" is as follows: 6.11.1. The GROUP SEQUENCE parameter (key 0x00) identifies the group within the track to start delivering objects.  The publisher MUST start delivering the objects from the most recent group, when this parameter is omitted.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.11.2. The OBJECT SEQUENCE parameter (key 0x01) identifies the object with the track to start delivering objects.  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.  This parameter is applicable in SUBSCRIBE REQUEST message. 6.11.3. AUTHORIZATION INFO parameter (key 0x02) identifies track's authorization information.  This parameter is populated for cases where the authorization is required at the track level.  This parameter is applicable in SUBSCRIBE REQUEST and ANNOUNCE messages. </ins> 7. TODO: Expand this section.
Original text:
8. <del> TODO: fill out currently missing registries: * MOQT version numbers * SETUP parameters * Track Request parameters * Subscribe Error codes * Announce Error codes * Track format numbers * Message types * Object headers </del>  TODO: register the URI scheme and the ALPN

Reviewer comments:
Following from discussions in , this PR allows a given publishers to un-announce a track namespace to indicate that it is not longer accepting new subscribe requests. The high-level call flow for happy path is as below
Individual Review

Revised text:
8.  <ins> TODO: fill out currently missing registries: MOQT version numbers SETUP parameters Track Request parameters Subscribe Error codes Announce Error codes Track format numbers Message types Object headers </ins> TODO: register the URI scheme and the ALPN
Original text:
Media over QUIC Transport <del> draft-ietf-moq-transport-00 </del>  Abstract

Reviewer comments:
Can we PLEASE number editor's drafts as draft-ietf-moq-transport-latest? Currently, it says draft-00, which can result is significant confustion with respect to the last published draft and creates an unstable interop target.
+1 this shouldn't have been checked in.

Revised text:
Media over QUIC Transport  <ins> draft-ietf-moq-transport-latest </ins> Abstract
Original text:
A OBJECT message contains a range of contiguous bytes from from the specified track, as well as associated metadata required to deliver, <del> cache, and forward it. </del>  The format of the OBJECT message is as follows:

Reviewer comments:
and . There was consensus in Cambridge that removing the special meaning of zero length gets rid of difficult code, removes potental foot guns, saves a byte, and enables actual zero length payloads, which supposedly has use cases.
Since message (6. Messages) will be the main piece of info of MOQ I think we should try to minimize its size. Assuming most of the messages send to the wire will be objects inside a quic stream, the length should be NOT needed. Could we use 1 bit in "type" to indicate if length is present, we could save some bytes without overcomplicating the protocol
The length of a QUIC stream is only known after the FIN bit is received(ie the end of QUIC stream). Putting the length in the message header can ensure the size of stream is known at the beginning of the stream.
The size of an OBJECT is a varint so that's a single byte when 0. Even in the situation where you're sending an OBJECT per frame, that's what like 100 OBJECTs per second?. That's 100B/s while the media might average 375,000B/s (3Mb/s). But yeah, we can optimize when the draft is closer to completion and things are more concrete. I like how QUIC STREAM frames are encoded, where the frame type indicates if fields are present (ex. length).
This issue is related to the question of what types of lengths we'll support, and whether we'll support those that go to the end of a quic stream (aka infinite length). "unknown" payloads where they're a delimiter of some sort had no support, because you have to do extra parsing. This issue is about two types: Object and Object + Length, which has support from the WG. Martin to roll into PR
From Cambridge: Martin will put this in a separate PR once lands

Revised text:
A OBJECT message contains a range of contiguous bytes from from the specified track, as well as associated metadata required to deliver,  <ins> cache, and forward it.  There are two subtypes of this message.  When the message type is 0x00, the optional Object Payload Length field is present.  When the message type ix 0x02, the field is not present. </ins> The format of the OBJECT message is as follows:
Original text:
send-order or priority ordering-by-priorities value. Object Payload Length: The length of the following Object Payload. <del> The sender MAY encode a zero in this field, which means that the message continues to the end of the stream. </del>  Object Payload: An opaque payload intended for the consumer and SHOULD NOT be processed by a relay.

Reviewer comments:
and . There was consensus in Cambridge that removing the special meaning of zero length gets rid of difficult code, removes potental foot guns, saves a byte, and enables actual zero length payloads, which supposedly has use cases.
Since message (6. Messages) will be the main piece of info of MOQ I think we should try to minimize its size. Assuming most of the messages send to the wire will be objects inside a quic stream, the length should be NOT needed. Could we use 1 bit in "type" to indicate if length is present, we could save some bytes without overcomplicating the protocol
The length of a QUIC stream is only known after the FIN bit is received(ie the end of QUIC stream). Putting the length in the message header can ensure the size of stream is known at the beginning of the stream.
The size of an OBJECT is a varint so that's a single byte when 0. Even in the situation where you're sending an OBJECT per frame, that's what like 100 OBJECTs per second?. That's 100B/s while the media might average 375,000B/s (3Mb/s). But yeah, we can optimize when the draft is closer to completion and things are more concrete. I like how QUIC STREAM frames are encoded, where the frame type indicates if fields are present (ex. length).
This issue is related to the question of what types of lengths we'll support, and whether we'll support those that go to the end of a quic stream (aka infinite length). "unknown" payloads where they're a delimiter of some sort had no support, because you have to do extra parsing. This issue is about two types: Object and Object + Length, which has support from the WG. Martin to roll into PR
From Cambridge: Martin will put this in a separate PR once lands

Revised text:
send-order or priority ordering-by-priorities value. Object Payload Length: The length of the following Object Payload.  <ins> If this field is absent, the object payload continues to the end of the stream. </ins> Object Payload: An opaque payload intended for the consumer and SHOULD NOT be processed by a relay.
Original text:
The subscriber making the subscribe request is notified of the result of the subscription, via "SUBSCRIBE OK" (message-subscribe-ok) or the <del> "SUBSCRIBE ERROR" message-subscribe-error control message. </del>  For successful subscriptions, the publisher maintains a list of subscribers for each full track name.  Each new OBJECT belonging to

Reviewer comments:
one question is if they come on different streams can they get out order
My inclination is to send a SubscriptionEnd {} message with appropriate Reason Code set. This will help to support the case that we discussed on publisher wanting to indicate wanting to stop publishing
SUBSCRIPTIONEND and SUBSCRIPTIONEND_ERROR could be split for the graceful vs non-graceful cases.
Discussion in room seems to be rather not have an error after OK but instead use new messages or in subscribe_end message
I'd like to consolidate messages at some point, but we can revisit later.

Revised text:
The subscriber making the subscribe request is notified of the result of the subscription, via "SUBSCRIBE OK" (message-subscribe-ok) or the  <ins> "SUBSCRIBE ERROR" message-subscribe-error control message.  The entity receiving the SUBSCRIBE MUST send only a single response to a given SUBSCRIBE of either an OK or ERROR. </ins> For successful subscriptions, the publisher maintains a list of subscribers for each full track name.  Each new OBJECT belonging to
Original text:
specific (typically based on prior business agreement). Relays respond with "ANNOUNCE OK" and/or "ANNOUNCE ERROR" control <del> messages providing the results of announcement. </del>  OBJECT message header carry short hop-by-hop Track Id that maps to the Full Track Name (see message-subscribe-ok).  Relays use the Track

Reviewer comments:
one question is if they come on different streams can they get out order
My inclination is to send a SubscriptionEnd {} message with appropriate Reason Code set. This will help to support the case that we discussed on publisher wanting to indicate wanting to stop publishing
SUBSCRIPTIONEND and SUBSCRIPTIONEND_ERROR could be split for the graceful vs non-graceful cases.
Discussion in room seems to be rather not have an error after OK but instead use new messages or in subscribe_end message
I'd like to consolidate messages at some point, but we can revisit later.

Revised text:
specific (typically based on prior business agreement). Relays respond with "ANNOUNCE OK" and/or "ANNOUNCE ERROR" control  <ins> messages providing the results of announcement.  The entity receiving the ANNOUNCE MUST send only a single response to a given ANNOUNCE of either an OK or ERROR. </ins> OBJECT message header carry short hop-by-hop Track Id that maps to the Full Track Name (see message-subscribe-ok).  Relays use the Track
Original text:
prioritize streams (priority-congestion) based on the send order/ priority.  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 to be buffered in the QUIC library, awaiting in order delivery, which

Reviewer comments:
Also, can someone explain what the following paragraph is saying, because I'm having a difficult time parsing it.
The next paragraph is trying to say that if you receive HoL blocked stream data at a relay you should try to forward what you have. The goal is to mitigate accumulating latency at every relay hop. I think this makes sense in two cases: You receive data that you know to be within an object you have already seen the header for. Eg: the object length is 100 and you miss bytes 0-49 but get 50-99, you can forward 50-99, as long as your QUIC library supports out of order reads and writes to a stream (not many presently do). This also applies when the object has no length and occupies the entire stream. You are missing some object data for object N on a stream, but you receive the header for object N + 1. This is (potentially) less problematic since the relay might be able to open a new stream to forward it, so out-of-order stream write APIs are not required. In any case, the text probably needs clarification, and perhaps moving from SHOULD (but we know you won't) to MAY is warranted?
Should we mention that a relay should start sending object as soon as the object can be identified (after the header)? Since the draft points out latency as a big deal, it seems this is a must have if we want to cover ULL cases
+1.
It used to be in but was removed. The text was pretty simple: I think and the agreement was to put it into some non-existent latency section.
+1 We should add a recommendation text for Relays to address the request from NAME
sooner is better I do think this might be interpreted by some people in an over zealous sort of way ( like turning off nagle type things ). I do wonder about just using MAY. But happy either way. SHOULD and MAY mean the same thing.

Revised text:
prioritize streams (priority-congestion) based on the send order/ priority. <ins> A sender SHOULD begin sending incomplete objects when available to avoid incurring additional latency. </ins> 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 to be buffered in the QUIC library, awaiting in order delivery, which
Original text:
WebTransport.  Both provide streams and datagrams with similar semantics (see I-D.ietf-webtrans-overview); thus, the main difference lies in how the servers are identified and how the connection is <del> established. </del>  3.1.1.

Reviewer comments:
Issue raised at interim on Feb 1, 2023: Does the protocol need to define a failover if QUIC is not available on a specific path. If so, is it the same failover in all cases?
Note that WebTransport does provide a failover to HTTP/2.
We need a answer for Raw QUIC too
We discussed this in chartering and came down on a hard no. It just makes things too complicated. Yep, the webtransport version of it might work fine on TCP and we are not out to break that but it is not a design goal. This is about media over QUIC and QUIC is over UDP. The CDNs may internally do whatever they do but that is a black box.
I agree that this is out of scope, based on my reading of the charter, which says "can be used over raw QUIC or WebTransport." I would like to either close with no action or we can add editorial text that notes that all paths may not support QUIC.
It was decided that a sentence or two about this, including a note that the appropriate fallback may be something entirely different from MoQ (ie: DASH/HLS/etc) depending upon the application and deployment.

Revised text:
WebTransport.  Both provide streams and datagrams with similar semantics (see I-D.ietf-webtrans-overview); thus, the main difference lies in how the servers are identified and how the connection is  <ins> established.  There is no definition of the protocol over other transports, such as TCP, and applicaitons using MoQ might need to fallback to another protocol when QUIC or WebTransport aren't available. </ins> 3.1.1.
Original text:
other uses of bidirectional streams, a peer MAY currently close the connection if it receives a second bidirectional stream. <del> The control stream MUST NOT be abruptly closed at the QUIC layer. Doing so results in the session being closed as a 'Protocol Violation'. </del>  3.3. <del> QUIC streams aside from the control stream MAY be canceled due to </del>  congestion or other reasons by either the sender or receiver.  Early <del> termination of a QUIC stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </del>  3.4.

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:
other uses of bidirectional streams, a peer MAY currently close the connection if it receives a second bidirectional stream.  <ins> 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'. </ins> 3.3.  <ins> Streams aside from the control stream MAY be canceled due to </ins> congestion or other reasons by either the sender or receiver.  Early  <ins> termination of a stream does not affect the MoQ application state, and therefore has no effect on outstanding subscriptions. </ins> 3.4.