jiebi/TextFlow huggingface dataset:
Original text:
allow the end of a Message to still be sent. The simpler form of Send that does not take any messageContext is <del> equivalent to passing a default messageContext with not values added. </del>  If an application wants to override Message Properties for a specific <del> message, it can acquire an empty messageContext Object and add all </del>  desired Message Properties to that Object.  It can then reuse the same messageContext Object for sending multiple Messages with the same properties. <del> Parameters may be added to a messageContext object only before the </del>  context is used for sending.  Once a messageContext has been used <del> with a Send call, modifying any of its parameters is invalid. </del>  Message Properties may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is

Reviewer comments:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Revised text:
allow the end of a Message to still be sent. The simpler form of Send that does not take any messageContext is  <ins> equivalent to passing a default MessageContext with not values added. </ins> If an application wants to override Message Properties for a specific  <ins> message, it can acquire an empty MessageContext Object and add all </ins> desired Message Properties to that Object.  It can then reuse the same messageContext Object for sending multiple Messages with the same properties.  <ins> Properties may be added to a MessageContext object only before the </ins> context is used for sending.  Once a messageContext has been used  <ins> with a Send call, modifying any of its properties is invalid. </ins> Message Properties may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is
Original text:
Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. <del> The following Message Context Parameters are supported: </del>  7.3.1.

Reviewer comments:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Revised text:
Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error.  <ins> The following Message Properties are supported: </ins> 7.3.1.
Original text:
The following example sends a Message in two separate calls to Send. <del> All messageData sent with the same messageContext object will be treated as belonging to the same Message, and will constitute an in- order series until the endOfMessage is marked.  Once the end of the Message is marked, the messageContext object may be re-used as a new Message with identical parameters. </del>  7.5.

Reviewer comments:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Revised text:
The following example sends a Message in two separate calls to Send.  <ins> All data sent with the same MessageContext object will be treated as belonging to the same Message, and will constitute an in-order series until the endOfMessage is marked.  Once the end of the Message is marked, the MessageContext object may be re-used as a new Message with identical parameters. </ins> 7.5.
Original text:
invoke Receive again. Multiple invocations of ReceivedPartial deliver data for the same <del> Message by passing the same messageContext, until the endOfMessage </del>  flag is delivered or a ReceiveError occurs.  All partial blocks of a single Message are delivered in order without gaps.  This event does not support delivering discontiguous partial Messages.

Reviewer comments:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Revised text:
invoke Receive again. Multiple invocations of ReceivedPartial deliver data for the same  <ins> Message by passing the same MessageContext, until the endOfMessage </ins> flag is delivered or a ReceiveError occurs.  All partial blocks of a single Message are delivered in order without gaps.  This event does not support delivering discontiguous partial Messages.
Original text:
conditions that irrevocably lead to the termination of the Connection are signaled using ConnectionError instead (see termination). <del> The ReceiveError event passes an optional associated messageContext. </del>  This may indicate that a Message that was being partially received previously, but had not completed, encountered an error and will not be completed.

Reviewer comments:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Revised text:
conditions that irrevocably lead to the termination of the Connection are signaled using ConnectionError instead (see termination).  <ins> The ReceiveError event passes an optional associated MessageContext. </ins> This may indicate that a Message that was being partially received previously, but had not completed, encountered an error and will not be completed.
Original text:
RFC7657 apply. The Capacity Profile for a selected protocol stack may be modified on <del> a per-Message basis using the Transmission Profile Message Context Property; see send-profile. </del>  9.2.

Reviewer comments:
Message Context Parameters/Properties are now Message Properties, and associated terminology cleanup. Addresses part of the resolution to .
Looks good, thanks for the cleanup!LGTM

Revised text:
RFC7657 apply. The Capacity Profile for a selected protocol stack may be modified on  <ins> a per-Message basis using the Transmission Profile Message Property; see send-profile. </ins> 9.2.
Original text:
Abstract This document provides an overview of the architecture of Transport <del> Services, a system for exposing the features of transport protocols to applications.  This architecture serves as a basis for Application Programming Interfaces (APIs) and implementations that provide flexible transport networking services.  It defines the common set of terminology and concepts to be used in more detailed discussion of Transport Services. </del>  1.

Reviewer comments:
Thanks for these fixes! I did a bit of reworking of the abstract, but it keeps the main part of the changes you made.
Regarding the sentence you removed, that was an adaption of an existing sentence, which I believe aimed to mention the words implementation and API to implicitly refere to the other docs (which was probably too subtle for anybody to notice anyway). However, the other change I made to that sentence was to mention one of the benefits / deployment incentives for taps (dynamic protocol and path selection). I wasn't sure about the wording here, but I think it would be good to (re-)add a sentence to the abstract saying why taps is so great and that everybody should deploy it.
Yes, the original second sentence was aimed at mentioning that there were two other documents, API and Implementation, that would be based on this one. I liked how in your revision, it did try to make things clearer than just saying "flexible transport networking services", but I felt that the specific example of dynamic path and protocol selection was a bit too specific for that one line. (I was chatting with NAME about this as I was editing, btw). My thought was that the list of features that you added in right after that, which go through the top-level bullet points of the advantages, do a more comprehensive job of summarizing the benefit.

Revised text:
Abstract This document provides an overview of the architecture of Transport  <ins> Services, a model for exposing transport protocol features to applications for network communication.  In contrast to what is provided by most existing Application Programming Interfaces (APIs), it is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams.  This document further defines the common set of terminology and concepts to be used in definitions of APIs and implementations. </ins> 1.
Original text:
applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can optimize its behavior based on the <del> application requirements and network conditions. </del>  This document is developed in parallel with the specification of the Transport Services API I-D.ietf-taps-interface and Implementation I- <del> D.ietf-taps-impl documents. </del>  1.1.

Reviewer comments:
Thanks for these fixes! I did a bit of reworking of the abstract, but it keeps the main part of the changes you made.
Regarding the sentence you removed, that was an adaption of an existing sentence, which I believe aimed to mention the words implementation and API to implicitly refere to the other docs (which was probably too subtle for anybody to notice anyway). However, the other change I made to that sentence was to mention one of the benefits / deployment incentives for taps (dynamic protocol and path selection). I wasn't sure about the wording here, but I think it would be good to (re-)add a sentence to the abstract saying why taps is so great and that everybody should deploy it.
Yes, the original second sentence was aimed at mentioning that there were two other documents, API and Implementation, that would be based on this one. I liked how in your revision, it did try to make things clearer than just saying "flexible transport networking services", but I felt that the specific example of dynamic path and protocol selection was a bit too specific for that one line. (I was chatting with NAME about this as I was editing, btw). My thought was that the list of features that you added in right after that, which go through the top-level bullet points of the advantages, do a more comprehensive job of summarizing the benefit.

Revised text:
applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can optimize its behavior based on the  <ins> application requirements and network conditions, without requiring a change to the application.  Further, this flexibility does not only enable faster deployment of new feature and protocols, it can also support applications with racing and fallback mechanisms which today usually need to be implemented in each application separately. </ins> This document is developed in parallel with the specification of the Transport Services API I-D.ietf-taps-interface and Implementation I-  <ins> D.ietf-taps-impl documents.  Although following the Transport Services Architecture does of course not mean that all APIs and implementations have to be identical, agreeing on a common minimal set of features and representing them in a similar fashion improves the ability to easily port applications from one system to the another. </ins> 1.1.
Original text:
Delimiter-separated formats, such as HTTP/1.1. Common Message Framers can be provided by the Transport Services <del> implementation, but an implemention ought to allow custom Message </del>  Framers to be defined by the application or some other piece of software.  This section describes one possible interface for defining Message Framers as an example.

Reviewer comments:
Just some points about the new text on framers in the API draft: In 10.2 it is specified in which order multiple framers run on incoming and outgoing messages, it is however never specified what the order looks like on Start and Stop events. In 10.6, "MessageFramer.DeliverAndAdvanceReceiveCursor" appears to be missing the "Data" argument that is present in "MessageFramer.Deliver". Also in 10.6, in the second paragraph it says: When it is probably meant to say While the framer implementation is able to notify the Connection that it has finished handling a Start event (by calling MessageFramer.MakeConnectionReady), there is no such way for Stop events.
As notes for the responses to these points: If there are multiple framers, the "lowest" one (the one closest to the transport) would receive start first, and the next would get the start event when the lower one is ready. Similar for stop. Good calls on the missing data argument and the typo re application vs framer. I was thinking to use the failConnection call to complete a stop, potentially with no error?

Revised text:
Delimiter-separated formats, such as HTTP/1.1. Common Message Framers can be provided by the Transport Services  <ins> implementation, but an implementation ought to allow custom Message </ins> Framers to be defined by the application or some other piece of software.  This section describes one possible interface for defining Message Framers as an example.
Original text:
implementation to communicate control data to the remote endpoint that can be used to parse Messages.  At any time if the implementation encounters a fatal error, it can also cause the Connection to fail and provide an error.  Before an implementation marks a Message Framer as ready, it can also dynamically add a protocol or framer above it in the stack.  This allows protocols like STARTTLS, that need to add TLS conditionally,

Reviewer comments:
Just some points about the new text on framers in the API draft: In 10.2 it is specified in which order multiple framers run on incoming and outgoing messages, it is however never specified what the order looks like on Start and Stop events. In 10.6, "MessageFramer.DeliverAndAdvanceReceiveCursor" appears to be missing the "Data" argument that is present in "MessageFramer.Deliver". Also in 10.6, in the second paragraph it says: When it is probably meant to say While the framer implementation is able to notify the Connection that it has finished handling a Start event (by calling MessageFramer.MakeConnectionReady), there is no such way for Stop events.
As notes for the responses to these points: If there are multiple framers, the "lowest" one (the one closest to the transport) would receive start first, and the next would get the start event when the lower one is ready. Similar for stop. Good calls on the missing data argument and the typo re application vs framer. I was thinking to use the failConnection call to complete a stop, potentially with no error?

Revised text:
implementation to communicate control data to the remote endpoint that can be used to parse Messages. <ins> Similarly, when a Message Framer generates a "Stop" event, the framer implementation has the opportunity to write some final data or clear up its local state before the "Closed" event is delivered to the Application.  The framer implementation can indicate that it has finished with this. </ins> At any time if the implementation encounters a fatal error, it can also cause the Connection to fail and provide an error. <ins> Should the framer implementation deem the candidate selected during racing unsuitable it can signal this by failing the Connection prior to marking it as ready.  If there are no other candidates available, the Connection will fail.  Otherwise, the Connection will select a different candidate and the Message Framer will generate a new "Start" event. </ins> Before an implementation marks a Message Framer as ready, it can also dynamically add a protocol or framer above it in the stack.  This allows protocols like STARTTLS, that need to add TLS conditionally,
Original text:
Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting <del> data to the next protocol.  Implementations SHOULD ensure that there is a way to pass the original data through without copying to improve </del>  performance. To provide an example, a simple protocol that adds a length as a

Reviewer comments:
Just some points about the new text on framers in the API draft: In 10.2 it is specified in which order multiple framers run on incoming and outgoing messages, it is however never specified what the order looks like on Start and Stop events. In 10.6, "MessageFramer.DeliverAndAdvanceReceiveCursor" appears to be missing the "Data" argument that is present in "MessageFramer.Deliver". Also in 10.6, in the second paragraph it says: When it is probably meant to say While the framer implementation is able to notify the Connection that it has finished handling a Start event (by calling MessageFramer.MakeConnectionReady), there is no such way for Stop events.
As notes for the responses to these points: If there are multiple framers, the "lowest" one (the one closest to the transport) would receive start first, and the next would get the start event when the lower one is ready. Similar for stop. Good calls on the missing data argument and the typo re application vs framer. I was thinking to use the failConnection call to complete a stop, potentially with no error?

Revised text:
Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting  <ins> data back to the Message Framer, which will in turn send it to the next protocol.  Implementations SHOULD ensure that there is a way to pass the original data through without copying to improve </ins> performance. To provide an example, a simple protocol that adds a length as a
Original text:
discard a header once the content has been parsed). To deliver a Message to the application, the framer implementation <del> can either directly deliever data that it has allocated, or deliver a </del>  range of data directly from the underlying transport and <del> simulatenously advance the receive cursor. </del>  Note that "MessageFramer.DeliverAndAdvanceReceiveCursor" allows the framer implementation to earmark bytes as part of a Message even

Reviewer comments:
Just some points about the new text on framers in the API draft: In 10.2 it is specified in which order multiple framers run on incoming and outgoing messages, it is however never specified what the order looks like on Start and Stop events. In 10.6, "MessageFramer.DeliverAndAdvanceReceiveCursor" appears to be missing the "Data" argument that is present in "MessageFramer.Deliver". Also in 10.6, in the second paragraph it says: When it is probably meant to say While the framer implementation is able to notify the Connection that it has finished handling a Start event (by calling MessageFramer.MakeConnectionReady), there is no such way for Stop events.
As notes for the responses to these points: If there are multiple framers, the "lowest" one (the one closest to the transport) would receive start first, and the next would get the start event when the lower one is ready. Similar for stop. Good calls on the missing data argument and the typo re application vs framer. I was thinking to use the failConnection call to complete a stop, potentially with no error?

Revised text:
discard a header once the content has been parsed). To deliver a Message to the application, the framer implementation  <ins> can either directly deliver data that it has allocated, or deliver a </ins> range of data directly from the underlying transport and  <ins> simultaneously advance the receive cursor. </ins> Note that "MessageFramer.DeliverAndAdvanceReceiveCursor" allows the framer implementation to earmark bytes as part of a Message even
Original text:
A specialized feature could be required by an application only when using a specific protocol, and not when using others.  For example, <del> if an application is using UDP, it could require control over the checksum or fragmentation behavior for UDP; if it used a protocol to frame its data over a byte stream like TCP, it would not need these options.  In such cases, the API ought to expose the features in such a way that they take effect when a particular protocol is selected, but do not imply that only that protocol could be used.  For example, if the API allows an application to specify a preference to use a partial checksum, communication would not fail when a protocol such as TCP is selected, which uses a checksum covering the entire payload. </del>  Other specialized features, however, could be strictly required by an application and thus constrain the set of protocols that can be used.

Reviewer comments:
Addresses
The architecture draft uses UDP checksums as an example of a protocol-specific property in Section 3.2 and 4.1.2. I find this a bit confusing because in the Interface draft, checksum coverage is a Generic Connection Property (Section 11.1.2). Should we maybe use a different example of a protocol-specific property, such as the TCP User Timeout we have in the Interface draft?
Sure, we can switch the example around
Thanks, LGTM!Thanks – works

Revised text:
A specialized feature could be required by an application only when using a specific protocol, and not when using others.  For example,  <ins> if an application is using TCP, it could require control over the User Timeout Option for TCP; these options would not take effect for other transport protocols.  In such cases, the API ought to expose the features in such a way that they take effect when a particular protocol is selected, but do not imply that only that protocol could be used.  For example, if the API allows an application to specify a preference to use the User Timeout Option, communication would not fail when a protocol such as QUIC is selected. </ins> Other specialized features, however, could be strictly required by an application and thus constrain the set of protocols that can be used.
Original text:
Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection behavior of the Transport Services system; for example, a <del> protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection </del>  establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later.  Changes made to Connection

Reviewer comments:
Addresses
The architecture draft uses UDP checksums as an example of a protocol-specific property in Section 3.2 and 4.1.2. I find this a bit confusing because in the Interface draft, checksum coverage is a Generic Connection Property (Section 11.1.2). Should we maybe use a different example of a protocol-specific property, such as the TCP User Timeout we have in the Interface draft?
Sure, we can switch the example around
Thanks, LGTM!Thanks – works

Revised text:
Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection behavior of the Transport Services system; for example, a  <ins> protocol-specific Connection Property can express that if TCP is used, the implementation ought to use the User Timeout Option. Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection </ins> establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later.  Changes made to Connection