jiebi/TextFlow huggingface dataset:
Original text:
The format of "UNSUBSCRIBE" 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). </del>  6.8.

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 format of "UNSUBSCRIBE" is as follows:  <ins> Subscribe ID: Subscription Identifer as defined in message- subscribe-req. </ins> 6.8.
Original text:
The format of "SUBSCRIBE_FIN" 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). </del>  Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this 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:
The format of "SUBSCRIBE_FIN" is as follows:  <ins> Subscribe ID: Subscription identifier as defined in message- subscribe-req. </ins> Final Group: The largest Group Sequence sent by the publisher in an OBJECT message in this track.
Original text:
The format of "SUBSCRIBE_RST" 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). </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:
The format of "SUBSCRIBE_RST" is as follows:  <ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req. </ins> Error Code: Identifies an integer error code for subscription failure.
Original text:
This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no other uses of bidirectional streams, a peer MAY currently close the <del> connection if it receives a second bidirectional stream. </del>  The control stream MUST NOT be abruptly closed at the underlying transport layer.  Doing so results in the session being closed as a

Reviewer comments:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Revised text:
This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no other uses of bidirectional streams, a peer MAY currently close the  <ins> session as a 'Protocol Violation' 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
Original text:
length-delimited messages. An endpoint that receives an unknown message type MUST close the <del> connection. </del>  6.1.

Reviewer comments:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Revised text:
length-delimited messages. An endpoint that receives an unknown message type MUST close the  <ins> session. </ins> 6.1.
Original text:
Senders MUST NOT repeat the same parameter type in a message. Receivers SHOULD check that there are no duplicate parameters and <del> close the connection if found. </del>  Receivers ignore unrecognized parameters.

Reviewer comments:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Revised text:
Senders MUST NOT repeat the same parameter type in a message. Receivers SHOULD check that there are no duplicate parameters and  <ins> close the session as a 'Protocol Violation' if found. </ins> Receivers ignore unrecognized parameters.
Original text:
server MUST reply with one of the versions offered by the client.  If the server does not support any of the versions offered by the client, or the client receives a server version that it did not <del> offer, the corresponding peer MUST close the connection. </del>  [[RFC editor: please remove the remainder of this section before publication.]]

Reviewer comments:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Revised text:
server MUST reply with one of the versions offered by the client.  If the server does not support any of the versions offered by the client, or the client receives a server version that it did not  <ins> offer, the corresponding peer MUST close the session. </ins> [[RFC editor: please remove the remainder of this section before publication.]]
Original text:
possible values, which are of type varint: The client MUST send a ROLE parameter with one of the three values <del> specified above.  The server MUST close the connection if the ROLE </del>  parameter is missing, is not one of the three above-specified values, or it is different from what the server expects based on the application.

Reviewer comments:
I also wonder if Connection URL should be renamed to Session URL?
Part of PR has text "MUST close the connection if there are duplicates" It seems like we should be closing the session, and we should specify an error code.
I think this is editorial, but unsure because of "specify an error code"
I would prefer: instead of:

Revised text:
possible values, which are of type varint: The client MUST send a ROLE parameter with one of the three values  <ins> specified above.  The server MUST close the session if the ROLE </ins> parameter is missing, is not one of the three above-specified values, or it is different from what the server expects based on the application.
Original text:
5.3. <del> TODO: This section shall cover aspects of relay failover and protocol interactions. 5.4. TODO: This section shall cover reconnect considerations for clients when moving between the Relays. 5.5. </del> TODO: Refer to priority-congestion.  Add details to describe relay behavior when merging or splitting streams and interactions with congestion response. <del> 5.6. </del>  MOQT encodes the delivery information for a stream via OBJECT headers (message-object).

Reviewer comments:
I believe some of this is covered by the recently updated GOAWAY section and I'm not sure what else to add here.
I don't think these TODOs have been covered yet. That being said, I would rather we file issues for these so there can be a conversation, rather than litter the draft with TODOs.
I'm unsure what's unresolved, but if you can file new issues as appropriate and link them to this PR, that would be helpful.

Revised text:
5.3.  TODO: Refer to priority-congestion.  Add details to describe relay behavior when merging or splitting streams and interactions with congestion response.  <ins> 5.4. </ins> MOQT encodes the delivery information for a stream via OBJECT headers (message-object).
Original text:
The first stream opened is a client-initiated bidirectional control stream where the peers exchange SETUP messages (message-setup).  All <del> messages defined in this draft are sent on the control stream after the SETUP message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </del>  This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no

Reviewer comments:
I think the intent of the draft was clear but this makes it explicit not to open a uni stream before setup exchange is done.
It's unclear what messages are allowed to be sent or received during the SETUP handshake. Here's my intuition: Until receiving the SETUP, the client: MUST NOT send messages MUST buffer any received messages. Until receiving the SETUP, the server: MUST NOT send messages. MUST NOT receive messages. The client needs to buffer messages because the server is unaware of when the client receives the SETUP. There's no equivalent to HANDSHAKE_DONE, and adding something like that would add an RTT anyway.
A potential optimization exists if the message encoding if the same for all supported versions (invariants). For example, if the client only advertises support for versions 1,2,3 and those versions share the same SUBSCRIBE encoding and meaning. This seems unlikely, given a separate version was created in the first place, and seems very brittle. If this was the case, then the client could process any invariant messages immediately and buffer the others. However, the client still couldn't send messages unless the server buffered any received messages.
The most flexible optimization would be the one where you could encode the SUBSCRIBE_REQUEST for every version you offer as a field in SETUP parameters. TLS does not do exactly that, but there are some things in ClinetHello that are only applicable for certain versions.

Revised text:
The first stream opened is a client-initiated bidirectional control stream where the peers exchange SETUP messages (message-setup).  All  <ins> messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the SETUP message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </ins> This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no
Original text:
Subscribers interact with the Relays by sending a SUBSCRIBE (message- subscribe-req) control message for the tracks of interest.  Relays MUST ensure subscribers are authorized to access the content <del> associated with the Full Track Name.  The authorization information can be part of subscription request itself or part of the encompassing session.  The specifics of how a relay authorizes a user are outside the scope of this specification. </del>  The subscriber making the subscribe request is notified of the result of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the

Reviewer comments:
It's only used a few times and now that Namespace and Name are an opaque sequence of bytes, it's even less compelling.
Take the line from your drafts that says There is no valid way to parse the right hand of this. We have things like "Full Track Name Length" and "Full Track Name". I do not think we should have ambiguous syntax for things that require precision. I think it would also be good to have things that can be directly mapped to common programming languages. This moves beyound simply editorial, or specification is underspecified and ambiguous until we fix this.
One possible solution would be use underscore or CamelCase
Oh, and the longer we leave this dumpster fire, the more painful it will be to fix.
love it

Revised text:
Subscribers interact with the Relays by sending a SUBSCRIBE (message- subscribe-req) control message for the tracks of interest.  Relays MUST ensure subscribers are authorized to access the content  <ins> associated with the track.  The authorization information can be part of subscription request itself or part of the encompassing session. The specifics of how a relay authorizes a user are outside the scope of this specification. </ins> The subscriber making the subscribe request is notified of the result of the subscription, via SUBSCRIBE_OK (message-subscribe-ok) or the
Original text:
SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. For successful subscriptions, the publisher maintains a list of <del> subscribers for each full track name.  Each new OBJECT belonging to the track is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RST (see message-subscribe-rst). </del>  Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription

Reviewer comments:
It's only used a few times and now that Namespace and Name are an opaque sequence of bytes, it's even less compelling.
Take the line from your drafts that says There is no valid way to parse the right hand of this. We have things like "Full Track Name Length" and "Full Track Name". I do not think we should have ambiguous syntax for things that require precision. I think it would also be good to have things that can be directly mapped to common programming languages. This moves beyound simply editorial, or specification is underspecified and ambiguous until we fix this.
One possible solution would be use underscore or CamelCase
Oh, and the longer we leave this dumpster fire, the more painful it will be to fix.
love it

Revised text:
SUBSCRIBE of either SUBSCRIBE_OK or SUBSCRIBE_ERROR. For successful subscriptions, the publisher maintains a list of  <ins> subscribers for each track.  Each new OBJECT belonging to the track within the subscription range is forwarded to each active subscriber, dependent on the congestion response.  A subscription remains active until it expires, until the publisher of the track terminates the track with a SUBSCRIBE_FIN (see message-subscribe-fin) or a SUBSCRIBE_RST (see message-subscribe-rst). </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription
Original text:
of the Parameter Value field in bytes. Each parameter description will indicate the data type in the <del> Parameter Value field.  If the parameter value is a varint, but the self-encoded length of that varint does not match the Parameter Length field, the receiver MUST ignore the parameter using the value in the Parameter Length field. </del>  6.1.1.

Reviewer comments:
Currently, VarInts have two lengths: In the parameter length. In the first two bits of the parameter value. The decision in was that the two MUST match, which is a good solution without a full reform. However: Ignoring seems like the wrong play. For example, we know the role parameter (0x0) is a VarInt in the current draft. However this text says I MUST ignore any errors when parsing this varint and pretend like the parameter was never sent, which is both unenforceable and a major foot-gun (silently ignoring parameters). I think we close the connection with an error if there's an error parsing a known parameter.
If a parameter is unknown, then the parser doesn't know if the value is a varint and therefore can't check the length match. I thought it was better to have consistent behavior than not, because it's easier to write and easier to reason about. But if this has actual downstream consequences, I could be convinced otherwise.
I don't know what I was smoking when I came up with this title. My concern is that when a known parameter has the wrong length, the text says the decoder MUST ignore it. But it likely has the wrong length due to a bug, so this will cause unintended (non-fatal) behavior.
I understand what you mean. My point was that an unknown parameter has an inevitable result, and trying to make the processing for known parameters the same had some advantages. We'll discuss today.
Conclusion was to make it an error instead of skipping over the field if there's a length mismatch.
LG, though we can bikeshed about the error code name.

Revised text:
of the Parameter Value field in bytes. Each parameter description will indicate the data type in the  <ins> Parameter Value field.  If a receiver understands a parameter type, and the parameter length implied by that type does not match the Parameter Length field, the receiver MUST terminate the session with error code 'Parameter Length Mismatch'. </ins> 6.1.1.
Original text:
SUBSCRIBE_RST (see message-subscribe-rst). A relay MUST not reorder or drop objects received on a multi-object <del> stream when forwarding to subscribers. </del>  Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription

Reviewer comments:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Revised text:
SUBSCRIBE_RST (see message-subscribe-rst). A relay MUST not reorder or drop objects received on a multi-object  <ins> stream when forwarding to subscribers, unless it has application specific information. </ins> Relays MAY aggregate authorized subscriptions for a given track when multiple subscribers request the same track.  Subscription
Original text:
subscription request is cached and shared among the pending subscribers.  5.2. Publishing through the relay starts with publisher sending ANNOUNCE

Reviewer comments:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Revised text:
subscription request is cached and shared among the pending subscribers. <ins> The application SHOULD use a relevant error code in SUBSCRIBE_ERROR, as defined below: </ins> 5.2. Publishing through the relay starts with publisher sending ANNOUNCE
Original text:
5.4. MOQT encodes the delivery information for a stream via OBJECT headers <del> (message-object). </del>  A relay MUST treat the object payload as opaque.  A relay MUST NOT combine, split, or otherwise modify object payloads.  A relay SHOULD

Reviewer comments:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Revised text:
5.4. MOQT encodes the delivery information for a stream via OBJECT headers  <ins> (message-object).  A relay MUST NOT modify Object properties when forwarding. </ins> A relay MUST treat the object payload as opaque.  A relay MUST NOT combine, split, or otherwise modify object payloads.  A relay SHOULD
Original text:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a <del> sender sends an object.  The preferences are Track, Group, and Object.  An Object MUST be sent according to its "Object </del>  Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and

Reviewer comments:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Revised text:
send-order or priority ordering-by-priorities value. Object Forwarding Preference: An enumeration indicating how a  <ins> sender sends an object.  The preferences are Track, Group, Object and Datagram.  An Object MUST be sent according to its "Object </ins> Forwarding Preference", described below. Object Payload: An opaque payload intended for the consumer and
Original text:
Track Alias: Identifies the Track Namespace and Track Name as defined in message-subscribe-req. <del> The Track Namespace and Track Name identified by the Track Alias is different from the one specified in the subscription identified by </del>  Subscribe ID, the receiver MUST close the session with a Protocol Violation. Other fields: As described in canonical-object-fields.  6.3.3. When multiple objects are sent on a stream, the stream begins with a

Reviewer comments:
This was previously part of . It allows an object to be sent in a datagram f it fits, and put on a stream if it doesn't.
Linking some feedback raised in the original PR that has not yet been addressed: URL URL
Looks like a great starting point to me.

Revised text:
Track Alias: Identifies the Track Namespace and Track Name as defined in message-subscribe-req.  <ins> If the Track Namespace and Track Name identified by the Track Alias are different from those specified in the subscription identified by </ins> Subscribe ID, the receiver MUST close the session with a Protocol Violation. Other fields: As described in canonical-object-fields. <ins> An "OBJECT_PREFER_DATAGRAM" message carries a single object in a datagram or a stream.  There is no explicit length of the payload; it is determined by the length of the datagram or stream.  If this message appears on a stream, it MUST be the first message on a unidirectional stream. An Object received in an "OBJECT_PREFER_DATAGRAM" message has an "Object Forwarding Preference" = "Datagram". To send an Object with "Object Forwarding Preference" = "Datagram", determine the length of the fields and payload, and compare the length with the maximum datagram size of the session.  If the object size is less than or equal maximum datagram size, send the serialized data as a datagram.  Otherwise, open a stream, send the serialized data and terminate the stream.  An implementation SHOULD NOT send an Object with "Object Forwarding Preference" = "Datagram" on a stream if it is possible to send it as a datagram. </ins> 6.3.3. When multiple objects are sent on a stream, the stream begins with a