jiebi/TextFlow huggingface dataset:
Original text:
When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the <del> same "Object Send Order". </del>  All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".

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:
When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the  <ins> "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".
Original text:
new one and send the "STREAM_HEADER_TRACK" if needed, then serialize the the following object fields.  When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID". <del> All objects on the stream have the same "Object Send Order". </del>  All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group".

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:
new one and send the "STREAM_HEADER_TRACK" if needed, then serialize the the following object fields. <ins> A sender MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object ID is less than or equal to a previously sent Object ID within a given group on that stream. </ins> When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID".  <ins> All objects on the stream have the "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group".
Original text:
and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields.  6.3.4. Sending a track on one stream:

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:
and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. <ins> A sender MUST NOT send an Object on a stream if its Object ID is less than a previously sent Object ID within a given group in that stream. </ins> 6.3.4. Sending a track on one stream:
Original text:
objects from the group ID and object ID described above. If a publisher cannot satisfy the requested start or end for the <del> subscription it MAY send a SUBSCRIBE_ERROR with code TBD.  A publisher MUST NOT send objects from outside the requested start and end. </del>  TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.)

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:
objects from the group ID and object ID described above. If a publisher cannot satisfy the requested start or end for the  <ins> subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'. A publisher MUST NOT send objects from outside the requested start and end. </ins> TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.)
Original text:
Reason Phrase: Provides the reason for subscription error. <del> Track Alias: When Error Code is TBD, the subscriber SHOULD re- issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session-termination).  TODO: Add a registry for subscribe error codes and make this field conditional. </del>  6.7.

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:
Reason Phrase: Provides the reason for subscription error.  <ins> Track Alias: When Error Code is 'Retry Track Alias', the subscriber SHOULD re-issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session- termination). </ins> 6.7.
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:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

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:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

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:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

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:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

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:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

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 only 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
Original text:
When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the <del> same "Object Send Order". </del>  All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".

Reviewer comments:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Revised text:
When a stream begins with "STREAM_HEADER_TRACK", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID".  All objects on the stream have the  <ins> "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with STREAM_HEADER_TRACK have an "Object Forwarding Preference" = "Track".
Original text:
new one and send the "STREAM_HEADER_TRACK" if needed, then serialize the the following object fields.  When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID". <del> All objects on the stream have the same "Object Send Order". </del>  All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group".

Reviewer comments:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Revised text:
new one and send the "STREAM_HEADER_TRACK" if needed, then serialize the the following object fields. <ins> A sender MUST NOT send an Object on a stream if its Group ID is less than a previously sent Group ID on that stream, or if its Object ID is less than or equal to a previously sent Object ID within a given group on that stream. </ins> When a stream begins with "STREAM_HEADER_GROUP", all objects on the stream belong to the track requested in the Subscribe message identified by "Subscribe ID" and the group indicated by "Group ID".  <ins> All objects on the stream have the "Object Send Order" specified in the stream header. </ins> All Objects received on a stream opened with "STREAM_HEADER_GROUP" have an "Object Forwarding Preference" = "Group".
Original text:
and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields.  6.3.4. Sending a track on one stream:

Reviewer comments:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Revised text:
and "Object Send Order", or open a new one and send the "STREAM_HEADER_GROUP" if needed, then serialize the following fields. <ins> A sender MUST NOT send an Object on a stream if its Object ID is less than a previously sent Object ID within a given group in that stream. </ins> 6.3.4. Sending a track on one stream:
Original text:
objects from the group ID and object ID described above. If a publisher cannot satisfy the requested start or end for the <del> subscription it MAY send a SUBSCRIBE_ERROR with code TBD.  A publisher MUST NOT send objects from outside the requested start and end. </del>  TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.)

Reviewer comments:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Revised text:
objects from the group ID and object ID described above. If a publisher cannot satisfy the requested start or end for the  <ins> subscription it MAY send a SUBSCRIBE_ERROR with code 'Invalid Range'. A publisher MUST NOT send objects from outside the requested start and end. </ins> TODO: Define the flow where subscribe request matches an existing subscribe id (subscription updates.)
Original text:
Reason Phrase: Provides the reason for subscription error. <del> Track Alias: When Error Code is TBD, the subscriber SHOULD re- issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session-termination).  TODO: Add a registry for subscribe error codes and make this field conditional. </del>  6.7.

Reviewer comments:
Update main to reflect the tx-mode branch after was merged.
Agreed, but I'm not sure there's any normative language there. Is this a case of writing a paragraph cautioning that such limits could cause issues?
Whoa, I've missed some PRs, but LGTMIndividual Review: There was some feedback on previous iterations about this PR lacking guidance when encountering flow control limits (eg: send as datagram, relay converts to stream, but is out of streams or flow control)

Revised text:
Reason Phrase: Provides the reason for subscription error.  <ins> Track Alias: When Error Code is 'Retry Track Alias', the subscriber SHOULD re-issue the SUBSCRIBE with this Track Alias instead.  If this Track Alias is already in use, the receiver MUST close the connection with a Duplicate Track Alias error (session- termination). </ins> 6.7.
Original text:
This document uses the conventions detailed in (RFC9000) when describing the binary encoding. <del> This document also defines an additional field type for binary data: </del>  2.

Reviewer comments:
This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.

Revised text:
This document uses the conventions detailed in (RFC9000) when describing the binary encoding.  <ins> As a quick reference, the following list provides a non normative summary of the parts of RFC9000 field syntax that are used in this specification. This document extends the RFC9000 syntax and with the additional field types: To reduce unnecessary use of bandwidth, variable length integers SHOULD be encoded using the least number of bytes possible to represent the required value. </ins> 2.
Original text:
The basic data element of MOQT is an object.  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and potential dependencies. <del> model-group Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del>  2.2.

Reviewer comments:
This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.

Revised text:
The basic data element of MOQT is an object.  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and potential dependencies.  <ins> model-group An object is uniquely identified by its track namespace, track name, group ID, and object ID, and must be an identical sequence of bytes regardless of how or where it is retrieved.  An Object can become unavailable, but it's contents MUST NOT change over time. Objects are comprised of two parts: metadata and a payload.  The metadata is never encrypted and is always visible to relays.  The payload portion may be encrypted, in which case it is only visible to the producer and consumer.  The application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication. A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> 2.2.
Original text:
6.3.2.  An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and

Reviewer comments:
This PR cleans up some nits to make all the places we use the RFC9000 encoding syntax valid, updates our extensions to it, and add a non normative summary of parts of the syntax we use. I don't think this is making any changes to anything on the wire or normative changes to spec other than the statement SHOULD use smallest number of bytes for variable length integers which RFC9000 only requires for some fields.
I am not in love with the ABNF idea, but this is non-controversial.

Revised text:
6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and