jiebi/TextFlow huggingface dataset:
Original text:
6.2.2.1. <del> The ROLE parameter (key 0x00) allows each endpoint to independently specify what functionality they support for the session.  It has three possible values, which are of type varint: Both endpoints MUST send a ROLE parameter with one of the three values specified above.  Both endpoints MUST close the session if the ROLE parameter is missing or is not one of the three above-specified values. 6.2.2.2. </del> The PATH parameter (key 0x01) allows the client to specify the path of the MoQ URI when using native QUIC (QUIC).  It MUST NOT be used by the server, or when WebTransport is used.  If the peer receives a

Reviewer comments:
The role somewhat limited what actions were valid, but it's not clear that was important. Also, some things can be limited by MAXSUBSCRIBEID now.
I understand that a ClientSetup is sent that includes the role of if the client only wants to send objects, the role of if it only wants to receive objects, and the role of if it wants to both send and receive objects. And I believe that basically only the following relationships can be established: Client: vs Server: Client: vs Server: Client: vs Server: My questions are as follows: If a ClientSetup with or role parameters were to arrive at an ingestion-only server, how would the server handle it? Is it required that the server returns that the client does not expect and the client understands the server's intention? If a client that has already sent or receives a ServerSetup containing , is it acceptable to use that connection as is? There may be some security risks in this case. Thank you!
As a side note, if the conclusion in will be that Role Parameter is unnecessary or no consideration are required as endpoint behavior, then this issue would be unnecessary.
Not clear what the use case is. Seems like a foot gun in that it can be set wrong for how the connection is used.
I don't care if we leave it or keep it. Just adding this as I got questions about why have it.
Having the client voluntarily declare itself to abide by a certain role is not preventing the relay form having to do any work. A malicious client will declare one role but then act differently. Any relay open to the public has to protect itself against unauthorized ANNOUNCE and SUBSCRIBE control messages, irrespective of what role was declared. Therefore the upfront role declaration is superfluous.
I tend to agree it's not doing anything helpful here, and sent out to remove it.
Only suggestion to adjust other setup parameter keys now that you have removed 0x00. Given we don't have a strong need for this, glad to see it go for now and we can add back later if we find a strong need for it.

Revised text:
6.2.2.1.  The PATH parameter (key 0x01) allows the client to specify the path of the MoQ URI when using native QUIC (QUIC).  It MUST NOT be used by the server, or when WebTransport is used.  If the peer receives a
Original text:
the URI; if "query" is present, the client MUST concatenate "?", followed by the "query" portion of the URI to the parameter. <del> 6.2.2.3. </del>  The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The

Reviewer comments:
The role somewhat limited what actions were valid, but it's not clear that was important. Also, some things can be limited by MAXSUBSCRIBEID now.
I understand that a ClientSetup is sent that includes the role of if the client only wants to send objects, the role of if it only wants to receive objects, and the role of if it wants to both send and receive objects. And I believe that basically only the following relationships can be established: Client: vs Server: Client: vs Server: Client: vs Server: My questions are as follows: If a ClientSetup with or role parameters were to arrive at an ingestion-only server, how would the server handle it? Is it required that the server returns that the client does not expect and the client understands the server's intention? If a client that has already sent or receives a ServerSetup containing , is it acceptable to use that connection as is? There may be some security risks in this case. Thank you!
As a side note, if the conclusion in will be that Role Parameter is unnecessary or no consideration are required as endpoint behavior, then this issue would be unnecessary.
Not clear what the use case is. Seems like a foot gun in that it can be set wrong for how the connection is used.
I don't care if we leave it or keep it. Just adding this as I got questions about why have it.
Having the client voluntarily declare itself to abide by a certain role is not preventing the relay form having to do any work. A malicious client will declare one role but then act differently. Any relay open to the public has to protect itself against unauthorized ANNOUNCE and SUBSCRIBE control messages, irrespective of what role was declared. Therefore the upfront role declaration is superfluous.
I tend to agree it's not doing anything helpful here, and sent out to remove it.
Only suggestion to adjust other setup parameter keys now that you have removed 0x00. Given we don't have a strong need for this, glad to see it go for now and we can add back later if we find a strong need for it.

Revised text:
the URI; if "query" is present, the client MUST concatenate "?", followed by the "query" portion of the URI to the parameter.  <ins> 6.2.2.2. </ins> The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The
Original text:
When a relay receives an incoming ANNOUCE for a given namespace, for each active upstream subscription that matches that namespace, it <del> SHOULD send a SUBSCRIBE to that publisher that send the ANNOUNCE. </del>  OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use

Reviewer comments:
As I was reading through the draft, I found some slight typos in the publisher interactions segment. This fixes them!

Revised text:
When a relay receives an incoming ANNOUCE for a given namespace, for each active upstream subscription that matches that namespace, it  <ins> SHOULD send a SUBSCRIBE to the publisher that sent the ANNOUNCE. </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
Original text:
When a stream begins with "STREAM_HEADER_SUBGROUP", all objects on the stream belong to the track requested in the Subscribe message <del> identified by "Subscribe ID" and the subgroup indicated by 'Group ID' </del>  and "Subgroup ID". All Objects received on a stream opened with "STREAM_HEADER_SUBGROUP"

Reviewer comments:
As of now, we use Subscribe ID for operations on a subscriber, and Track Alias for operations on objects. In , there was an effort to remove referencing subscribe id within object header types, but one slipped through. This fixes that.

Revised text:
When a stream begins with "STREAM_HEADER_SUBGROUP", all objects on the stream belong to the track requested in the Subscribe message  <ins> identified by "Track Alias" and the subgroup indicated by 'Group ID' </ins> and "Subgroup ID". All Objects received on a stream opened with "STREAM_HEADER_SUBGROUP"
Original text:
Subscribe ID value is a 'Protocol Violation'. Subscribe ID: The new Maximum Subscribe ID for the session.  If a <del> Subscribe ID equal or larger than this is received in any message, including SUBSCRIBE, the publisher MUST close the session with an error of 'Too Many Subscribes'.  More on Subscribe ID in message- subscribe-req. </del>  6.21.

Reviewer comments:
This is an attempt at clarifying MAXSUBSCRIBEID, feel free to make suggestions.
lgtm
In 6.16 of draft 6, the draft says that "receipt of a MAXSUBSCRIBEID message with an equal or smaller Subscribe ID value is a 'Protocol Violation'." ; however, later the section mentions that "If a Subscribe ID equal or larger than this is received in any message, including SUBSCRIBE, the publisher MUST close the session with an error of 'Too Many Subscribes'." This is can be ambiguous because technically MAXSUBSCRIBEID is any message. Should all sessions be closed if MAXSUBSCRIBEID message contains an invalid Subscribe ID value? Does any message exclude MAXSUBSCRIBEID if an invalid Subscribe ID value is provided? Clarification on this would be helpful. Thank you!
lgtmAgree with Alan's comment. Otherwise LGTM

Revised text:
Subscribe ID value is a 'Protocol Violation'. Subscribe ID: The new Maximum Subscribe ID for the session.  If a  <ins> Subscribe ID message-subscribe-req equal or larger than this is received by the publisher that sent the MAX_SUBSCRIBE_ID, the publisher MUST close the session with an error of 'Too Many Subscribes'. </ins> 6.21.
Original text:
.  A schedulable object in MoQT is either: <del> An object that belongs to a peep where that object would be the next object to be sent in that peep. </del>  An object that belongs to a track with delivery preference Datagram. <del> Since a single peep or datagram has a single publisher priority, it can be useful to conceptualize this process as scheduling peeps or datagrams instead of individual objects on them. </del>  A

Reviewer comments:
(recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM

Revised text:
.  A schedulable object in MoQT is either:  <ins> An object that belongs to a subgroup where that object would be the next object to be sent in that subgroup. </ins> An object that belongs to a track with delivery preference Datagram.  <ins> Since a single subgroup or datagram has a single publisher priority, it can be useful to conceptualize this process as scheduling subgroups or datagrams instead of individual objects on them. </ins> A
Original text:
what happens to objects that have already been received and possibly scheduled. <del> is a priority number associated with an indiviaul schedulable object. It is specified in the header of the respective peep or datagram, and is the same for all objects in a single peep. </del>  is a property of an invidual subscription.  It can be either 'Ascending' (groups with lower group ID are sent first), or

Reviewer comments:
(recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM

Revised text:
what happens to objects that have already been received and possibly scheduled.  <ins> is a priority number associated with an individual schedulable object.  It is specified in the header of the respective subgroup or datagram, and is the same for all objects in a single subgroup. </ins> is a property of an invidual subscription.  It can be either 'Ascending' (groups with lower group ID are sent first), or
Original text:
If two objects belong to the same group of the same track received through the same subscription, the one with <del> (for tracks with delivery preference Peep), or </del>  (for tracks with delivery preference Datagram) is sent first.

Reviewer comments:
(recently merged) uses "Peep" where the rest of the draft now uses "SubGroup" Personally, I wouldn't mind going back to "Peep" since we seem to keep using that term conversationally, but either way, the draft should use one name or the other, not both.
Chairs do you want to reopen this ?
Chair Comment: The working group has aligned on subgroup as the nomenclature in the document. Of course mistakes happen but let's just correct them and move on.
Oops, that was an error.
LGTM

Revised text:
If two objects belong to the same group of the same track received through the same subscription, the one with  <ins> (for tracks with delivery preference Subgroup), or </ins> (for tracks with delivery preference Datagram) is sent first.
Original text:
6.1.1.1. <del> AUTHORIZATION INFO parameter (key 0x02) identifies a track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or ANNOUNCE message.  This parameter is populated for cases where the </del>  authorization is required at the track level.  The value is an ASCII string. 6.1.1.2. <del> 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.  There is no explicit signal that an Object was not sent because the delivery timeout was exceeded. </del>  If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription.  The publisher SHOULD

Reviewer comments:
Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good

Revised text:
6.1.1.1.  <ins> AUTHORIZATION INFO parameter (Parameter Type 0x02) identifies a track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or ANNOUNCE message.  This parameter is populated for cases where the </ins> authorization is required at the track level.  The value is an ASCII string. 6.1.1.2.  <ins> The DELIVERY TIMEOUT parameter (Parameter Type 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.  There is no explicit signal that an Object was not sent because the delivery timeout was exceeded. </ins> If both the subscriber and publisher specify the parameter, they use the min of the two values for the subscription.  The publisher SHOULD
Original text:
6.1.1.3. <del> MAX_CACHE_DURATION (key 0x04): An integer expressing a number of milliseconds.  If present, the relay MUST NOT start forwarding any individual Object received through this subscription after the specified number of milliseconds has elapsed since the beginning of the Object was received.  This means Objects earlier in a multi- object stream will expire earlier than Objects later in the stream. Once Objects have expired, their state becomes unknown, and a relay that handles a subscription that includes those Objects re-requests them. </del>  6.2.

Reviewer comments:
Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good

Revised text:
6.1.1.3.  <ins> MAX_CACHE_DURATION (Parameter Type 0x04): An integer expressing a number of milliseconds.  If present, the relay MUST NOT start forwarding any individual Object received through this subscription after the specified number of milliseconds has elapsed since the beginning of the Object was received.  This means Objects earlier in a multi-object stream will expire earlier than Objects later in the stream.  Once Objects have expired, their state becomes unknown, and a relay that handles a subscription that includes those Objects re- requests them. </ins> 6.2.
Original text:
6.2.2.1. <del> The PATH parameter (key 0x01) allows the client to specify the path of the MoQ URI when using native QUIC (QUIC).  It MUST NOT be used by the server, or when WebTransport is used.  If the peer receives a PATH parameter from the server, or when WebTransport is used, it MUST close the connection.  It follows the URI formatting rules RFC3986. </del>  When connecting to a server using a URI with the "moqt" scheme, the client MUST set the PATH parameter to the "path-abempty" portion of

Reviewer comments:
Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good

Revised text:
6.2.2.1.  <ins> The PATH parameter (Parameter Type 0x01) allows the client to specify the path of the MoQ URI when using native QUIC (QUIC).  It MUST NOT be used by the server, or when WebTransport is used.  If the peer receives a PATH parameter from the server, or when WebTransport is used, it MUST close the connection.  It follows the URI formatting rules RFC3986. </ins> When connecting to a server using a URI with the "moqt" scheme, the client MUST set the PATH parameter to the "path-abempty" portion of
Original text:
6.2.2.2. <del> The MAX_SUBSCRIBE_ID parameter (key 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The default value is 0, so if not specified, the peer MUST NOT create subscriptions. </del>  6.3.

Reviewer comments:
Section 6.2.2.1 (Role) and section 6.2.2.2 (PATH) indicate and . Shouldn't key be ?
The "parameters" syntax is defined in section 6.1 as: We should be consistent, and refer to "Parameter Type 0x1", etc.
Minor nit , otherwise Looks Good

Revised text:
6.2.2.2.  <ins> The MAX_SUBSCRIBE_ID parameter (Parameter Type 0x02) communicates an initial value for the Maximum Subscribe ID to the receiving subscriber.  The default value is 0, so if not specified, the peer MUST NOT create subscriptions. </ins> 6.3.
Original text:
Objects are assigned an intended delivery order that should be obeyed during congestion (delivery-order) <del> Objects can be dependent on other objects, in which case reordering is required (dependencies). </del> The decoder receives each objects and skips any objects that do not arrive in time (decoder).

Reviewer comments:
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.

Revised text:
Objects are assigned an intended delivery order that should be obeyed during congestion (delivery-order)  The decoder receives each objects and skips any objects that do not arrive in time (decoder).
Original text:
MAY overlap with other objects.  This means timestamps may be interleaved between objects. <del> MAY reference frames in other objects, but only if listed as a dependency. </del> Media objects are encoded using a specified container (containers). 4.2.

Reviewer comments:
It's difficult to populate and has fringe benefit at best. Let's revisit this in the future if it's actually useful. removed after discussion in
To explain a bit more in-depth: The goal of the dependency list was to give relays the information required to know which frames are droppable. This doesn't actually accomplish that goal since a frame could be a reference for a future frame. It's a lot of state to keep track of and it's unlikely to be used by even the smartest relay. It's much simpler and probably a better user experience for a relay to obey the delivery order. The decoder doesn't actually need this list since the references are stored in the codec itself. A mismatch between the Warp dependency list and the codec reference list sounds pretty awful. Accurately populating the Warp dependency list requires parsing the codec bitstream, which is more difficult and expensive than it needs to be. The only immediate use-case for the dependency list is to mark init segments. We could have a separate field for that, or put the init segment in the CATALOG itself. There's a possible use-case for SVC but again, a relay can just follow delivery order and the decoder should be able to piece together dependencies from the underlying codec.
I went ahead and merged because I haven't heard a positive reaction to the dependency list. We can always make a PR to add it back and actually discuss the merits.

Revised text:
MAY overlap with other objects.  This means timestamps may be interleaved between objects.  Media objects are encoded using a specified container (containers). 4.2.