jiebi/TextFlow huggingface dataset:
Original text:
4.5. <del> Warp encodes the delivery information for each stream via a "HEADERS" frame (headers).  This MUST be at the start of each stream so it is easy for a relay to parse. </del>  A relay SHOULD prioritize streams (prioritization) based on the delivery order.  A relay MAY change the delivery order, in which case

Reviewer comments:
Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.

Revised text:
4.5.  <ins> Warp encodes the delivery information for a stream via SEGMENT headers (segment). </ins> A relay SHOULD prioritize streams (prioritization) based on the delivery order.  A relay MAY change the delivery order, in which case
Original text:
5.1. <del> The "HEADERS" message contains information required to deliver, cache, and forward a stream.  This message SHOULD be parsed and obeyed by any Warp relays. </del>  "id".  An unique identifier for the stream.  This field is optional and MUST be unique if set.

Reviewer comments:
Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.

Revised text:
5.1.  <ins> A SEGMENT message contains a single segment associated with a specified track, as well as associated metadata required to deliver, cache, and forward it. The header of the SEGMENT message is as follows: </ins> "id".  An unique identifier for the stream.  This field is optional and MUST be unique if set.
Original text:
(dependencies).  This field is optional and the default value is an empty array. <del> 5.2. A "SEGMENT" message consists of a segment in a fragmented MP4 container. </del>  Each segment MUST start with an initialization fragment, or MUST depend on a segment with an initialization fragment.  An

Reviewer comments:
Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.

Revised text:
(dependencies).  This field is optional and the default value is an empty array.  <ins> The payload of the SEGMENT message is a fragmented MP4 container. </ins> Each segment MUST start with an initialization fragment, or MUST depend on a segment with an initialization fragment.  An
Original text:
between overhead and latency.  It is RECOMMENDED that a media fragment consists of a single frame to minimize latency. <del> 5.3. The "APP" message contains arbitrary contents.  This is useful for metadata that would otherwise have to be shoved into the media bitstream. Relays MUST NOT differentiate between streams containing "SEGMENT" and "APP" frames.  The same forwarding and caching behavior applies to both as specified in the"HEADERS" frame. 5.4. </del>  The "GOAWAY" message is sent by the server to force the client to reconnect.  This is useful for server maintenance or reassignments

Reviewer comments:
Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.

Revised text:
between overhead and latency.  It is RECOMMENDED that a media fragment consists of a single frame to minimize latency.  <ins> 5.2. </ins> The "GOAWAY" message is sent by the server to force the client to reconnect.  This is useful for server maintenance or reassignments
Original text:
guarantee that a publisher will not have already sent Objects before the new start Object.  The end Object MUST NOT increase and when it decreases, there is no guarantee that a publisher will not have <del> already sent Objects after the new end Object. </del>  Unlike a new subscription, SUBSCRIBE_UPDATE can not cause an Object to be delivered multiple times.  Like SUBSCRIBE, EndGroup and

Reviewer comments:
This case seems easily avoidable by a subscriber, so the simplest option is to close the session.
Draft 04 currently doesn't mention about sending any response when the SUBSCRIBE_UPDATE is successful or when it fails even though the draft hints on possible failures The above suggests that an error should be sent to inform the client that it is making invalid subscription updates.
documents some other aspects of SUBSCRIBE_UPDATE that are underspecified.
Table 4 is missing SUBSCRIBEUPDATE, so there's no code for this message type. Section 6.5 doesn't say what to do when the update is malformed, in some way. SUBSCRIBEERROR? Is a bogus SUBSCRIBE_UPDATE ignored, or does it nuke the original subscribe?
One nit, but LGTMLGTM

Revised text:
guarantee that a publisher will not have already sent Objects before the new start Object.  The end Object MUST NOT increase and when it decreases, there is no guarantee that a publisher will not have  <ins> already sent Objects after the new end Object.  A publisher SHOULD close the Session as a 'Protocol Violation' if the SUBSCRIBE_UPDATE violates either rule or if the subscriber specifies a Subscribe ID that does not exist within the Session. </ins> Unlike a new subscription, SUBSCRIBE_UPDATE can not cause an Object to be delivered multiple times.  Like SUBSCRIBE, EndGroup and
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:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
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:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
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:
parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string.  6.2. The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages

Reviewer comments:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM

Revised text:
parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. <ins> 6.1.1.2. The DELIVERY TIMEOUT parameter (key 0x03) MAY appear in a SUBSCRIBE, SUBSCRIBE_OK, or a SUBSCRIBE_UDPATE message.  It is the duration in milliseconds the relay SHOULD continue to attempt forwarding Objects after they have been received.  The start time for the timeout is based on when the beginning of the Object is received, and does not depend upon the forwarding preference. If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription.  The publisher SHOULD always specify the value received from an upstream subscription when there is one, and nothing otherwise.  If an earlier Object arrives later than subsequent Objects, relays can consider the receipt time as that of the next later Object, with the assumption that the Object's data was reordered. If neither the subscriber or publisher specify DELIVERY TIMEOUT, Objects are delivered as indicated by their Group Order and Priority. When sent by a subscriber, this parameter is intended to be specific to a subscription, so it SHOULD NOT be forwarded upstream by a relay that intends to serve multiple subscriptions for the same track. Publishers SHOULD consider whether the entire Object is likely to be delivered before sending any data for that Object, taking into account priorities, congestion control, and any other relevant information. </ins> 6.2. The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages
Original text:
Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track <del> Namespace to reduce overhead.  If the Track Alias is already in use, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </del>  Track Namespace: Identifies the namespace of the track as defined in (track-name).

Reviewer comments:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM

Revised text:
Track Alias: A session specific identifier for the track. Messages that reference a track, such as OBJECT (message-object), reference this Track Alias instead of the Track Name and Track  <ins> Namespace to reduce overhead.  If the Track Alias is already being used for a different track, the publisher MUST close the session with a Duplicate Track Alias error (session-termination). </ins> Track Namespace: Identifies the namespace of the track as defined in (track-name).
Original text:
largest Group ID for this track.  This field is only present if ContentExists has a value of 1.  6.13. A publisher sends a SUBSCRIBE_ERROR control message in response to a

Reviewer comments:
Pulls in some text from and attempts to convey the conclusions of the Seattle interim. Adds Subscribe Parameters to SUBSCRIBEOK to allow this parameter to be optional in SUBSCRIBEOK.
LGTM

Revised text:
largest Group ID for this track.  This field is only present if ContentExists has a value of 1. <ins> Subscribe Parameters: The parameters are defined in version- specific-params. </ins> 6.13. A publisher sends a SUBSCRIBE_ERROR control message in response to a
Original text:
preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. <del> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. </del>  An Object received in an "OBJECT_STREAM" message has an "Object Forwarding Preference" = "Object".

Reviewer comments:
This had consensus in the past, but a PR wasn't written. Particularly now that we have Object Status, which is optional for all other mappings, it makes sense to add the length and make things consistent.
In our current encoding, you can stream objects without knowing their length in advance if your forwarding preference is Object or Datagram, but not if it's Track or Stream (since those require explicit lengths in the front). I feel like those two aspects should not be tied: we should either support or not support streaming for all preferences.
Individual Comment: In order to stream multiple objects with unknown lengths in a multi-object stream, you'd need additional framing. Alternately, we could create single-object variants of the TRACK and GROUP stream header.
I agree it's weird to have a mix of unframed and framed messages. While I prefer unframed streams... I think we should state that MoQ objects are always framed, represent a single point in time, and have a known length. It's an optimization to withhold the length in the datagram and dedicated stream case but maybe we should include it.
In meeting we decided add a length to everything. We can add extension later to have no length if we need ( Thanks to Mike E for suggestion )
LGTM

Revised text:
preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'.  <ins> An "OBJECT_STREAM" message carries a single object on a stream.  An "OBJECT_STREAM" message MUST be the first and only message on a unidirectional stream. </ins> An Object received in an "OBJECT_STREAM" message has an "Object Forwarding Preference" = "Object".
Original text:
Other fields: As described in canonical-object-fields. An "OBJECT_DATAGRAM" message carries a single object in a datagram. <del> There is no explicit length of the payload; it is determined by the length of the datagram. </del> An Object received in an "OBJECT_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram".  To send an Object with "Object

Reviewer comments:
This had consensus in the past, but a PR wasn't written. Particularly now that we have Object Status, which is optional for all other mappings, it makes sense to add the length and make things consistent.
In our current encoding, you can stream objects without knowing their length in advance if your forwarding preference is Object or Datagram, but not if it's Track or Stream (since those require explicit lengths in the front). I feel like those two aspects should not be tied: we should either support or not support streaming for all preferences.
Individual Comment: In order to stream multiple objects with unknown lengths in a multi-object stream, you'd need additional framing. Alternately, we could create single-object variants of the TRACK and GROUP stream header.
I agree it's weird to have a mix of unframed and framed messages. While I prefer unframed streams... I think we should state that MoQ objects are always framed, represent a single point in time, and have a known length. It's an optimization to withhold the length in the datagram and dedicated stream case but maybe we should include it.
In meeting we decided add a length to everything. We can add extension later to have no length if we need ( Thanks to Mike E for suggestion )
LGTM

Revised text:
Other fields: As described in canonical-object-fields. An "OBJECT_DATAGRAM" message carries a single object in a datagram.  An Object received in an "OBJECT_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram".  To send an Object with "Object