jiebi/TextFlow huggingface dataset:
Original text:
16.3. <del> The delivery order (delivery-order depends on the desired user experience during congestion: </del>  <del> if media should be skipped: delivery order = PTS </del>  <del> if media should not be skipped: delivery order = -PTS </del>  <del> if video should be skipped before audio: audio delivery order < video delivery order </del>  <del> The delivery order may be changed if the content changes.  For example, switching from a live stream (skippable) to an advertisement </del>  (unskippable).

Reviewer comments:
Matches the terminology used by W3C is generally much better. This is the order at which objects are sent, but does not guarantee delivery in this order. Doesn't preclude further conversations about prioritization.
This is just a rename so maybe merge it after fixing conflicts (you'll need another approval), or abandon? Based on the discussion today we'll be updating the priority section to indicate other possibilities for expressing priority.
Looks good to me. I would like to see this merged soon, so we can make the proper references to "send order" in the additional PRs.I do think that send order make more sense than delivery order but the parts of this that have to do with the prioritization scheme should probably be moved to a new section of the draft where we talk about the algorithms to decide what to send next.

Revised text:
16.3.  <ins> The send order (send-order depends on the desired user experience during congestion: </ins>  <ins> if media should be skipped: send order = PTS </ins>  <ins> if media should not be skipped: send order = -PTS </ins>  <ins> if video should be skipped before audio: audio send order < video send order </ins>  <ins> The send order may be changed if the content changes.  For example, switching from a live stream (skippable) to an advertisement </ins> (unskippable).
Original text:
Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del>  1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del>  motivation covers the background and rationale behind MoQ transport.

Reviewer comments:
NAME does the latest commit address your feedback? thanks
lgtm modulo addressing Luke's comment.

Revised text:
Abstract  <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1.  <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.
Original text:
Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del>  1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del>  motivation covers the background and rationale behind MoQ transport.

Reviewer comments:
NAME does the updated text with OPEN ISSUE looks about right to you. I personally feel we should revisit all the terms and get to a common understaning across the documents. For -05 an OPEN ISSUE seems like OK. thoughts ?
LGTM

Revised text:
Abstract  <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1.  <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.
Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  Commonly used terms in this document are described below. 1.3.

Reviewer comments:
NAME does the updated text with OPEN ISSUE looks about right to you. I personally feel we should revisit all the terms and get to a common understaning across the documents. For -05 an OPEN ISSUE seems like OK. thoughts ?
LGTM

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> TODO: The terms defined here doesn't capture the ongoing discussions within the Working Group (either as part of requirements or architecture documents).  This section will be updated to reflect the discussions. </ins> Commonly used terms in this document are described below. 1.3.
Original text:
Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del>  1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del>  motivation covers the background and rationale behind MoQ transport.

Reviewer comments:
NAME please check the latest commit . thanks
Something is wrong, this PR appears blank
editorial nit if it can be addressed, otherwise LGTM

Revised text:
Abstract  <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1.  <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.
Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  Commonly used terms in this document are described below. 1.3.

Reviewer comments:
NAME please check the latest commit . thanks
Something is wrong, this PR appears blank
editorial nit if it can be addressed, otherwise LGTM

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> TODO: The terms defined here doesn't capture the ongoing discussions within the Working Group (either as part of requirements or architecture documents).  This section will be updated to reflect the discussions. </ins> Commonly used terms in this document are described below. 1.3.
Original text:
2.  2.1. <del> The basic element of MoQTransport is an </del>  .  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and <del> potential dependencies. model-group Objects carry associated metadata such as priority, TTL, or other information usable by a relay, but relays MUST treat the object payload as opaque. The application is solely responsible for the contents of objects. 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. A <del> is collection of objects, part of a larger track (model-track). A group behaves as a join point for subscriptions.  A new subscriber may not want to receive the entire track, and will instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. The application is responsible for how objects are placed into groups.  In general, objects within a group SHOULD NOT depend on objects in other groups. </del>  2.3. A <del> is a sequence of objects (model-object) organized into groups (model- group).  A subscriber can request individual tracks at group boundaries, including any new objects while the track is active. </del>  2.3.1.

Reviewer comments:
NAME please check the latest commit . thanks
Something is wrong, this PR appears blank
editorial nit if it can be addressed, otherwise LGTM

Revised text:
2. <ins> MoQT has a hierarchical object model for data, comprised of objects, groups and tracks. </ins> 2.1.  <ins> The basic data element of MoQTransport is an </ins> .  An object is an addressable unit whose payload is a sequence of bytes.  All objects belong to a group, indicating ordering and  <ins> potential dependencies. 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. </ins> 2.2. A  <ins> is a collection of objects and is a sub-unit of a track (model- track).  Objects within a group SHOULD NOT depend on objects in other groups.  A group behaves as a join point for subscriptions.  A new subscriber might not want to receive the entire track, and may instead opt to receive only the latest group(s).  The sender then selectively transmits objects based on their group membership. </ins> 2.3. A  <ins> is a sequence of groups (model-group).  It is the entity against which a consumer issues a subscription request.  A subscriber can request to receive individual tracks starting at a group boundary, including any new objects pushed by the producer while the track is active. </ins> 2.3.1.
Original text:
specific to the underlying transport protocol usage transport- protocols. <del> 2.4. A transport session is established for each track bundle.  The client issues a CONNECT request with a URL which the server uses for identification and authentication.  All control messages and prioritization occur within the context of a single transport session, which means a single track bundle.  When WebTransport is used, multiple transport sessions may be pooled over a single QUIC connection for efficiency. </del> 3. <del> MoQTransport works by transferring objects over QUIC streams.  The application determines how live content is fragmented into tracks, groups, and objects. </del> 3.1. At the point of this writing, the working group has not reached

Reviewer comments:
This PR by itself doesn't make a lot of sense but I'm ok rolling with it if it's part of the grand plan

Revised text:
specific to the underlying transport protocol usage transport- protocols.  3.  3.1. At the point of this writing, the working group has not reached
Original text:
Abstract <del> This document defines the core behavior for MoQTransport, a live media transport protocol over QUIC.  The application fragments a live stream into objects, including a header that describes the basic relationship between objects.  Objects are starved/dropped during congestion based on priorities in order to minimize latency. </del>  1. <del> MoQTransport is a live media transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport.  It was originally developed for live media, but has been generalized for similar use-cases. </del>  motivation covers the background and rationale behind MoQ transport.

Reviewer comments:
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.

Revised text:
Abstract  <ins> This document defines the core behavior for MoQTransport, a media transport protocol over QUIC.  MoQTransport allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints.  It supports intermediate content distribution networks and is designed for high scale and low latency distribution. </ins> 1.  <ins> MoQTransport (MoQT) is a transport protocol that utilizes the QUIC network protocol QUIC, either directly or via WebTransport WebTransport, for the dissemination of media.  MoQT utilizes a publish/subscribe workflow in which producers of media publish data in response to subscription requests from a multiplicity of endpoints.  MoQT supports wide range of use-cases with different resiliency and latency (live, interactive) needs without compromising the scalability and cost effectiveness associated with content delivery networks. MoQTransport is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MoQT objects, along with policies for discovery and subscription. </ins> motivation covers the background and rationale behind MoQ transport.
Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  Commonly used terms in this document are described below. 1.3.

Reviewer comments:
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> TODO: The terms defined here doesn't capture the ongoing discussions within the Working Group (either as part of requirements or architecture documents).  This section will be updated to reflect the discussions. </ins> Commonly used terms in this document are described below. 1.3.
Original text:
specific to the underlying transport protocol usage transport- protocols. <del> 2.4. A transport session is established for each track bundle.  The client issues a CONNECT request with a URL which the server uses for identification and authentication.  All control messages and prioritization occur within the context of a single transport session, which means a single track bundle.  When WebTransport is used, multiple transport sessions may be pooled over a single QUIC connection for efficiency. </del> 3. <del> MoQTransport works by transferring objects over QUIC streams.  The application determines how live content is fragmented into tracks, groups, and objects. </del> 3.1. At the point of this writing, the working group has not reached

Reviewer comments:
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.

Revised text:
specific to the underlying transport protocol usage transport- protocols.  3.  3.1. At the point of this writing, the working group has not reached
Original text:
group.  The two proposals are listed in send-order and ordering-by- priorities.  We expect further work before a consensus is reached. <del> 3.2. TODO: Add text describing iteration of group and intra object priorities within a group and their relation to congestion response. Add how it refers to </del> 4. This document defines a protocol that can be used interchangeably

Reviewer comments:
NAME I think you added this TODO but it got removed in the editorial pass, are you good with that?
Yes, we can remove this. We will certainly revisit the issue later, because this is a thorny subject. For example, we assume that "objects MUST not depend from objects in the group that have a higher priority code or a higher object ID" -- object at P2 does not depend on another object at P3, object number 1000 cannot depend on object number 2001. That much has consensus, but it is a negative statement.

Revised text:
group.  The two proposals are listed in send-order and ordering-by- priorities.  We expect further work before a consensus is reached.  4. This document defines a protocol that can be used interchangeably
Original text:
<del> Media over QUIC - Transport </del>  draft-lcurley-moq-transport-latest Abstract

Reviewer comments:
LGTMLGTM (side note for much much later, RFC editor often objects to acronyms in the title - but this is a future problem)

Revised text:
 <ins> Media over QUIC Transport </ins> draft-lcurley-moq-transport-latest Abstract
Original text:
how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription. <del> model describes the object model employed by MOQT </del>  session covers aspects of setting up a MOQT session.

Reviewer comments:
No real changes here (other than adding a missing period) but changes newlines for checker tools
LGTM, as it seems to just whitespaces only change.

Revised text:
how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription.  <ins> model describes the object model employed by MOQT. </ins> session covers aspects of setting up a MOQT session.
Original text:
The application MAY use any error message and SHOULD use a relevant code, as defined below: <del> Session Terminated No error occurred; however the endpoint wishes </del>  to terminate the session. <del> Generic Error An unclassified error occurred. </del>  Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.

Reviewer comments:
No real changes here (other than adding a missing period) but changes newlines for checker tools
LGTM, as it seems to just whitespaces only change.

Revised text:
The application MAY use any error message and SHOULD use a relevant code, as defined below:  <ins> Session Terminated: No error occurred; however the endpoint wishes </ins> to terminate the session.  <ins> Generic Error: An unclassified error occurred. </ins> Unauthorized: The endpoint breached an agreement, which MAY have been pre-negotiated by the application.
Original text:
client and the server; it allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called <del> ; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </del>  The wire format of the SETUP message is as follows:

Reviewer comments:
The stuff we had to italicize the stuff in html is inserting underscores in the .txt file so I just want to remove this until for now until we figure this out. Did not change anything other than making the words not italicized
Thanks for catching this , the rendered TXT file looks different for these things. Merging it for now and we can work on figuring out the right markdown syntax.

Revised text:
client and the server; it allows the peers to establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called  <ins> SETUP parameters; the semantics and format of which can vary based on whether the client or server is sending.  To ensure future extensibility of MOQT, the peers MUST ignore unknown setup parameters.  TODO: describe GREASE for those. </ins> The wire format of the SETUP message is as follows: