jiebi/TextFlow huggingface dataset:
Original text:
ContentExists: 1 if an object has been published on this track, 0 if not.  If 0, then the Largest Group ID and Largest Object ID <del> fields will not be present. </del>  Largest Group ID: The largest Group ID available for this track. This field is only present if ContentExists has a value of 1.

Reviewer comments:
This is a proposal to illustrate the changes needed to address one aspect of URL . In creating this, I explicitly didn't state copy the normative action on dealing with a 0 or 1 value. See URL for that.
9/25 interim: No objections to this direction, but make it MUST close if not 0 or 1. NAME can merge when he's satisfied the discussion has completed.
I updated this to use MUST.
https://moq-URL states This seems at odds with the QUIC design ethos of being very strict about receiving things that are obviously broken. This matter is wrapped up in URL and the proposed change (URL), so I wanted to track the question separately. I suspect we might want a bigger pass over the recomendations about when to detect a protocol error and how to handle it but I don't want to miss this specific issue in case it was done for a good reason.
I don't think this is editorial, since it affects the expectations on what a receiver is expected to do
To clarify, the proposal is to change the SHOULD terminate to a MUST terminate? I expect that's what everyone will do anyway, so this SG
Yes that would be my proposal here. And in addition, a separate review of other fields for consistency.
Discussed in today's interim. MUST rolled into URL and merged. So closing issue as done.
This change seems small and sensible, especially since every time I see (f) I think it's a float, not a flag.Don't feel strongly one way or the other but this looks good to me.

Revised text:
ContentExists: 1 if an object has been published on this track, 0 if not.  If 0, then the Largest Group ID and Largest Object ID  <ins> fields will not be present.  Any other value is a protocol error and MUST terminate the session with a Protocol Violation (session- termination). </ins> Largest Group ID: The largest Group ID available for this track. This field is only present if ContentExists has a value of 1.
Original text:
ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final <del> Object fields will not be present. </del>  Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.

Reviewer comments:
This is a proposal to illustrate the changes needed to address one aspect of URL . In creating this, I explicitly didn't state copy the normative action on dealing with a 0 or 1 value. See URL for that.
9/25 interim: No objections to this direction, but make it MUST close if not 0 or 1. NAME can merge when he's satisfied the discussion has completed.
I updated this to use MUST.
https://moq-URL states This seems at odds with the QUIC design ethos of being very strict about receiving things that are obviously broken. This matter is wrapped up in URL and the proposed change (URL), so I wanted to track the question separately. I suspect we might want a bigger pass over the recomendations about when to detect a protocol error and how to handle it but I don't want to miss this specific issue in case it was done for a good reason.
I don't think this is editorial, since it affects the expectations on what a receiver is expected to do
To clarify, the proposal is to change the SHOULD terminate to a MUST terminate? I expect that's what everyone will do anyway, so this SG
Yes that would be my proposal here. And in addition, a separate review of other fields for consistency.
Discussed in today's interim. MUST rolled into URL and merged. So closing issue as done.
This change seems small and sensible, especially since every time I see (f) I think it's a float, not a flag.Don't feel strongly one way or the other but this looks good to me.

Revised text:
ContentExists: 1 if an object has been published for this subscription, 0 if not.  If 0, then the Final Group and Final  <ins> Object fields will not be present.  Any other value is a protocol error and MUST terminate the session with a Protocol Violation (session-termination). </ins> Final Group: The largest Group ID sent by the publisher in an OBJECT message in this track.
Original text:
6.1.1.1. AUTHORIZATION INFO parameter (key 0x02) identifies a track's <del> authorization information in a SUBSCRIBE, SUBSCRIBE_NAMESPACE or </del>  ANNOUNCE message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string.

Reviewer comments:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

Revised text:
6.1.1.1. AUTHORIZATION INFO parameter (key 0x02) identifies a track's  <ins> authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or </ins> ANNOUNCE message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string.
Original text:
6.11. <del> The subscriber sends the SUBSCRIBE_NAMESPACE control message to a </del>  publisher to request the current set of matching announcements, as well as future updates to the set.

Reviewer comments:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

Revised text:
6.11.  <ins> The subscriber sends the SUBSCRIBE_ANNOUNCES control message to a </ins> publisher to request the current set of matching announcements, as well as future updates to the set.
Original text:
example, if the publisher is a relay that has received ANNOUNCE messages for namespaces ("example.com", "meeting=123", "participant=100") and ("example.com", "meeting=123", <del> "participant=200"), a SUBSCRIBE_NAMESPACE for ("example.com", </del>  "meeting=123") would match both. Parameters: The parameters are defined in version-specific-params. <del> The publisher will respond with SUBSCRIBE_NAMESPACE_OK or SUBSCRIBE_NAMESPACE_ERROR.  If the SUBSCRIBE_NAMESPACE is successful, </del>  the publisher will forward any matching ANNOUNCE messages to the subscriber that it has not yet sent.  If the set of matching ANNOUNCE messages changes, the publisher sends the corresponding ANNOUNCE or

Reviewer comments:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

Revised text:
example, if the publisher is a relay that has received ANNOUNCE messages for namespaces ("example.com", "meeting=123", "participant=100") and ("example.com", "meeting=123",  <ins> "participant=200"), a SUBSCRIBE_ANNOUNCES for ("example.com", </ins> "meeting=123") would match both. Parameters: The parameters are defined in version-specific-params.  <ins> The publisher will respond with SUBSCRIBE_ANNOUNCES_OK or SUBSCRIBE_ANNOUNCES_ERROR.  If the SUBSCRIBE_ANNOUNCES is successful, </ins> the publisher will forward any matching ANNOUNCE messages to the subscriber that it has not yet sent.  If the set of matching ANNOUNCE messages changes, the publisher sends the corresponding ANNOUNCE or
Original text:
A subscriber cannot make overlapping namespace subscriptions on a single session.  Within a session, if a publisher receives a <del> SUBSCRIBE_NAMESPACE with a Track Namespace Prefix that is a prefix of an earlier SUBSCRIBE_NAMESPACE or vice versa, it MUST respond with SUBSCRIBE_NAMESPACE_ERROR, with error code SUBSCRIBE_NAMESPACE_OVERLAP. </del>  The publisher MUST ensure the subscriber is authorized to perform this namespace subscription. <del> SUBSCRIBE_NAMESPACE is not required for a publisher to send ANNOUNCE </del>  and UNANNOUNCE messages to a subscriber.  It is useful in applications or relays where subscribers are only interested in or authorized to access a subset of available announcements. 6.12. <del> A subscriber issues a "UNSUBSCRIBE_NAMESPACE" message to a publisher </del>  indicating it is no longer interested in ANNOUNCE and UNANNOUNCE messages for the specified track namespace prefix. <del> The format of "UNSUBSCRIBE_NAMESPACE" is as follows: </del>  Track Namespace Prefix: As defined in message-subscribe-ns.

Reviewer comments:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

Revised text:
A subscriber cannot make overlapping namespace subscriptions on a single session.  Within a session, if a publisher receives a  <ins> SUBSCRIBE_ANNOUNCES with a Track Namespace Prefix that is a prefix of an earlier SUBSCRIBE_ANNOUNCES or vice versa, it MUST respond with SUBSCRIBE_ANNOUNCES_ERROR, with error code SUBSCRIBE_ANNOUNCES_OVERLAP. </ins> The publisher MUST ensure the subscriber is authorized to perform this namespace subscription.  <ins> SUBSCRIBE_ANNOUNCES is not required for a publisher to send ANNOUNCE </ins> and UNANNOUNCE messages to a subscriber.  It is useful in applications or relays where subscribers are only interested in or authorized to access a subset of available announcements. 6.12.  <ins> A subscriber issues a "UNSUBSCRIBE_ANNOUNCES" message to a publisher </ins> indicating it is no longer interested in ANNOUNCE and UNANNOUNCE messages for the specified track namespace prefix.  <ins> The format of "UNSUBSCRIBE_ANNOUNCES" is as follows: </ins> Track Namespace Prefix: As defined in message-subscribe-ns.
Original text:
6.20. <del> A publisher sends a SUBSCRIBE_NAMESPACE_OK control message for </del>  successful namespace subscriptions. Track Namespace Prefix: As defined in message-subscribe-ns. 6.21. <del> A publisher sends a SUBSCRIBE_NAMESPACE_ERROR control message in response to a failed SUBSCRIBE_NAMESPACE. </del>  Track Namespace Prefix: As defined in message-subscribe-ns.

Reviewer comments:
On the call today, people favored renaming to ANNOUNCES over ANNOUNCEMENTS, so I'll do that.
I call it . Because the subscriber is interested in any messages that match the prefix.
I agree with this. It is counterintuitive that SUBSCRIBE_NAMESPACE results in an ANNOUNCE request being sent to RELAY.
Speaking as an individual that came up with the name: It's terrible and anything the group comes up with is better. #sorry I'm fine with ANNOUNCEINTEREST. My suggestion is SUBSCRIBEANNOUNCEMENTS.
I like both ANNOUNCEINTEREST and SUBSCRIBEANNOUNCEMENTS. They are both long by the time we add OK and error to them. I wonder about just calling it INTEREST. I don't feel strongly about any of these names but I do like the idea of improving the name.
+1 This is clearer than ANNOUNCE-INTEREST, which is an ambiguous term for the uninitiated.

Revised text:
6.20.  <ins> A publisher sends a SUBSCRIBE_ANNOUNCES_OK control message for </ins> successful namespace subscriptions. Track Namespace Prefix: As defined in message-subscribe-ns. 6.21.  <ins> A publisher sends a SUBSCRIBE_ANNOUNCES_ERROR control message in response to a failed SUBSCRIBE_ANNOUNCES. </ins> Track Namespace Prefix: As defined in message-subscribe-ns.
Original text:
A subscription causes the publisher to send newly published objects for a track.  A subscriber MUST NOT make multiple active subscriptions for a track within a single session and publishers <del> SHOULD treat this as a protocol violation. </del>  The subscriber specifies a filter on the subscription to allow the publisher to identify which objects need to be delivered.

Reviewer comments:
Changes SUBSCRIBE so you can't go back farther than the current Group with any of the filter modes. If a SUBSCRIBE tries to go back farther, it is closed with a SUBSCRIBE_OK. Alternatively, instead of failing the subscription, we could specify that the SUBSCRIBE will be truncated and start at the beginning of the current group.
LGTM.
LGTM .. I had couple of questions on error condition to be MUST instead of SHOULD.

Revised text:
A subscription causes the publisher to send newly published objects for a track.  A subscriber MUST NOT make multiple active subscriptions for a track within a single session and publishers  <ins> SHOULD treat this as a protocol violation.  The only objects prior to the current object that can be requested are those in the current group. </ins> The subscriber specifies a filter on the subscription to allow the publisher to identify which objects need to be delivered.
Original text:
AbsoluteStart (0x3): Specifies an open-ended subscription beginning from the object identified in the StartGroup and StartObject fields.  AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and <del> StartObject. </del>  A filter type other than the above MUST be treated as error.  The format of SUBSCRIBE is as follows: Subscribe ID: The subscriber specified identifier used to manage a

Reviewer comments:
Changes SUBSCRIBE so you can't go back farther than the current Group with any of the filter modes. If a SUBSCRIBE tries to go back farther, it is closed with a SUBSCRIBE_OK. Alternatively, instead of failing the subscription, we could specify that the SUBSCRIBE will be truncated and start at the beginning of the current group.
LGTM.
LGTM .. I had couple of questions on error condition to be MUST instead of SHOULD.

Revised text:
AbsoluteStart (0x3): Specifies an open-ended subscription beginning from the object identified in the StartGroup and StartObject fields. <ins> If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </ins> AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and  <ins> StartObject.  If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </ins> A filter type other than the above MUST be treated as error. <ins> If a subscriber wants to subscribe to Objects both before and after the Latest Object, it can send a SUBSCRIBE for the Latest Object followed by a FETCH.  Depending upon the application, one might want to send both messages at the same time or wait for the first to return before sending the second. </ins> The format of SUBSCRIBE is as follows: Subscribe ID: The subscriber specified identifier used to manage a
Original text:
AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The <del> start and end of the range are inclusive.  EndGroup and EndObject MUST specify the same or a later object than StartGroup and StartObject.  If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </del>  A filter type other than the above MUST be treated as error.

Reviewer comments:
This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.

Revised text:
AbsoluteRange (0x4): Specifies a closed subscription starting at StartObject in StartGroup and ending at EndObject in EndGroup.  The  <ins> start and end of the range are inclusive.  EndGroup MUST specify the same or a later group than StartGroup.  If the StartGroup is prior to the current group, the publisher MUST reply with a SUBSCRIBE_ERROR with code 'Invalid Range'. </ins> A filter type other than the above MUST be treated as error.
Original text:
StartObject: The start Object ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types. <del> EndGroup: The end Group ID.  Only present for the "AbsoluteRange" filter type. EndObject: The end Object ID, plus 1.  A value of 0 means the entire group is requested.  Only present for the "AbsoluteRange" filter type. </del>  Subscribe Parameters: The parameters are defined in version- specific-params.

Reviewer comments:
This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.

Revised text:
StartObject: The start Object ID.  Only present for "AbsoluteStart" and "AbsoluteRange" filter types.  <ins> EndGroup: The end Group ID, inclusive.  Only present for the "AbsoluteRange" filter type. </ins> Subscribe Parameters: The parameters are defined in version- specific-params.
Original text:
EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended. <del> EndObject: The end Object ID, plus 1.  A value of 0 means the entire group is requested. </del> Subscriber Priority: Specifies the priority of a subscription relative to other subscriptions in the same session.  Lower numbers get higher priority.  See priorities.

Reviewer comments:
This is a dependency of Martin's Stream FIN/RESET PR,
Besides the fact that this simplifies the FIN logic, I really like that this frees the subscriber from either finding out the last object or sending object ID 2^62-1.

Revised text:
EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended.  Subscriber Priority: Specifies the priority of a subscription relative to other subscriptions in the same session.  Lower numbers get higher priority.  See priorities.
Original text:
is sent right after the last object in the track.  This SHOULD be cached. <del> 0x5 := Indicates end of Subgroup.  Object ID is one greater than the largest normal object ID in the Subgroup. </del> Any other value SHOULD be treated as a protocol error and terminate the session with a Protocol Violation (session-termination).  Any object with a status code other than zero MUST have an empty payload.

Reviewer comments:
We don't discuss how to use it anyway. This was suggested in
Done
There are references to EndOfSubgroup in the FIN PR, so one of the two PRs is going to have to delete them.

Revised text:
is sent right after the last object in the track.  This SHOULD be cached.  Any other value SHOULD be treated as a protocol error and terminate the session with a Protocol Violation (session-termination).  Any object with a status code other than zero MUST have an empty payload.
Original text:
received all objects in a subgroup from the start of the subscription.  If a relay, it can forward stream FINs to its own subscribers once those objects have been sent.  A relay MAY treat <del> receipt of EndOfGroup, EndOfSubgroup, GroupDoesNotExist, or EndOfTrack objects as a signal to close corresponding streams even if the FIN has not arrived, as further objects on the stream would be a protocol violation. </del>  Similarly, an EndOfGroup message indicates the maximum Object ID in the Group, so if all Objects in the Group have been received, a FIN

Reviewer comments:
We don't discuss how to use it anyway. This was suggested in
Done
There are references to EndOfSubgroup in the FIN PR, so one of the two PRs is going to have to delete them.

Revised text:
received all objects in a subgroup from the start of the subscription.  If a relay, it can forward stream FINs to its own subscribers once those objects have been sent.  A relay MAY treat  <ins> receipt of EndOfGroup, GroupDoesNotExist, or EndOfTrack objects as a signal to close corresponding streams even if the FIN has not arrived, as further objects on the stream would be a protocol violation. </ins> Similarly, an EndOfGroup message indicates the maximum Object ID in the Group, so if all Objects in the Group have been received, a FIN