jiebi/TextFlow huggingface dataset:
Original text:
The ROLE parameter is mandatory for the client.  All of the other parameters are optional. <del> 6.1.1.1. </del>  The ROLE parameter (key 0x00) allows the client to specify what roles it expects the parties to have in the MOQT connection.  It has three

Reviewer comments:
Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.

Revised text:
The ROLE parameter is mandatory for the client.  All of the other parameters are optional.  <ins> 6.1.2.1. </ins> The ROLE parameter (key 0x00) allows the client to specify what roles it expects the parties to have in the MOQT connection.  It has three
Original text:
or it is different from what the server expects based on the application. <del> 6.1.1.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

Reviewer comments:
Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.

Revised text:
or it is different from what the server expects based on the application.  <ins> 6.1.2.2. </ins> 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
Original text:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.8. </del>  The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.

Reviewer comments:
Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.

Revised text:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided.  <ins> 6.9. </ins> The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.
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:
Based on QUIC: URL
Based on call today, sounds like when running over QUIC we should also use an ALPN of "moq-13" for draft 13
When running over web transport, we need to talk to the web transport people to talk about what to do but the ALPN would be H3 (or whatever) so the answer is not ALPN
The conclusion was that we should move version negotiation out of the SETUP message and into an ALPN for native QUIC and an unspecified mechanism for WebTransport. However, I can't think of any replacement for WebTransport that would work today. Query parameters would work for passing the client supported versions but there's no mechanism for replying with the server selected version. The javascript API provides no information about connection establishment (ex. any returned headers), only that it completed. If we moved version negotiation out of SETUP, then it would not be possible to interop until new WebTransport functionality was deployed, assuming W3C agrees in the first place. Could we go ahead with this PR until there's an available alternative? I like the direction of utilizing more of the QUIC/WebTransport handshake, but I don't think we should block interop awaiting this marginally better design.
Can we add in the ALPN text as part of this PR and for now say something like "When QUIC is used, the negotiated alpn MUST match the value in the SETUP message."?
It's time to specify some version numbers so we can attempt interop. We should do something like QUIC, where draft versions are prefixed with 0xff (or something?).
+1 The QUIC guys way over engineered this so I would be fine with just doing the same thing so we don't need to bike shed on it.
For now, will go with lower bits are the draft number and upper bits are some fixed set of bits defined in the draft. Do roughly what QUIC did.
Here's what I propose we copy: URL We don't need semvar yet because each version WILL have breaking changes. I'd be totally fine with semvar for the final RFC, like one byte for the major/minor/revision. Although I also think that negotiating extensions is more flexible for a transport protocol, while semvar seems more useful for something intended for fanout like the catalog.
Per conversation, we've decided to move forward with this and do ALPN as a separate PR.I would want to consider using alpn at some point in time. Want to keep it open for URL version at some point too. This PR is fine to continue the experimentation.Looks fine to me. Sure we might do more complicated stuff later but this seems like good enough for now.

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:
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:
This PR moves track request params to its own section. This was messed up during huge PR merge as part of preparing for IETF117 work. Also it add track namespace length field to Announce_OK message which was omitted.
NAME good catch. updated the commit to address your comment. Thanks
It's an improvement so we should merge, but we do need to clean up how parameters are encoded.You may also want to move the actual definition of Track Request Parameter, it's currently in the SUBSCRIBE REQUEST section.

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:
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 moves track request params to its own section. This was messed up during huge PR merge as part of preparing for IETF117 work. Also it add track namespace length field to Announce_OK message which was omitted.
NAME good catch. updated the commit to address your comment. Thanks
It's an improvement so we should merge, but we do need to clean up how parameters are encoded.You may also want to move the actual definition of Track Request Parameter, it's currently in the SUBSCRIBE REQUEST section.

Revised text:
SHOULD remain connected on both connections for a short period, processing objects from both in parallel. <ins> 6.10. 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.10.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.10.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.10.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:
6.6. <del> A subscriber issues a "UNSUBSCRIBE REQUEST" message to a publisher indicating it is no longer interested in receiving media for the specified track. </del>  <del> The format of "UNSUBSCRIBE REQUEST" is as follows: </del>  Full Track Name: Identifies the track as defined in (track-name). <del> Track Request Parameters: As defined in track-req-params. </del> 6.7. <del> A "UNSUBSCRIBE OK" control message is sent in response to a successful "UNSUBSCRIBE REQUEST" message. Full Track Name: Identifies the track for which this response is provided. On successfully validating the "UNSUBSCRIBE REQUEST" message, the publisher SHOULD cease delivering objects for the track to the subscriber. 6.8. A publisher sends a "UNSUBSCRIBE ERROR" control message in response to a failed "UNSUBSCRIBE REQUEST" message Full Track Name: Identifies the track in the request message for which this response is provided. Error Code: Identifies an integer error code for the failure. Reason Phrase Length: The length in bytes of the reason phrase. Reason Phrase: Provides the reason for unsubscription error and "Reason Phrase Length" field carries its length. 6.9. </del> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is

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:
6.6.  <ins> A subscriber issues a "UNSUBSCRIBE" message to a publisher indicating it is no longer interested in receiving media for the specified track. </ins>  <ins> The format of "UNSUBSCRIBE" is as follows: </ins> Full Track Name: Identifies the track as defined in (track-name).  6.7.  The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBE REQUESTs for tracks within the announced Track Namespace.  The receiver verifies the publisher is
Original text:
Track Request Parameters: The parameters are defined in track-req- params. <del> 6.9.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.9.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.9.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.9.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, UNSUBSCRIBE and ANNOUNCE messages. 6.10. </del>  The receiver sends an "ANNOUNCE OK" control message to acknowledge the successful authorization and acceptance of an ANNOUNCE message.

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:
Track Request Parameters: The parameters are defined in track-req- params.  <ins> 6.8. </ins> The receiver sends an "ANNOUNCE OK" control message to acknowledge the successful authorization and acceptance of an ANNOUNCE message.
Original text:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided. <del> 6.11. </del>  The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.

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:
Track Namespace: Identifies the track namespace in the ANNOUNCE message for which this response is provided.  <ins> 6.9. </ins> The receiver sends an "ANNOUNCE ERROR" control message for tracks that failed authorization.
Original text:
Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length. <del> 6.12. </del>  The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without

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:
Reason Phrase: Provides the reason for announcement error and "Reason Phrase Length" field carries its length.  <ins> 6.10. 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.11. </ins> The server sends a "GOAWAY" message to force the client to reconnect. This is useful for server maintenance or reassignments without