jiebi/TextFlow huggingface dataset:
Original text:
if the chosen transport supports using multiple paths. The connection will negotiate the use of multiple paths if the <del> chosen transport supports this.  It will actively bring up paths based on the multipath policy (multipath-policy) selected by the application, as limited by the Interface Instance and Provisioning Domain Instance properties (see prop-interface and prop-pvd). </del>  The connection will support the use of multiple paths if the <del> remote endpoint requests it.  The connection will not actively initiate the use of any new paths, but will accept paths initiated by the remote endpoint. </del>  The policy for using multiple paths is specified using the separate "multipath-policy" property, see multipath-policy below.  To enable

Reviewer comments:
Sorry we just merged the multipath part into the API doc but I think there is still an issue about this part: 'Active: : The connection will negotiate the use of multiple paths if the chosen transport supports this. It will actively bring up paths based on the multipath policy ({{multipath-policy}}) selected by the application, as limited by the Interface Instance and Provisioning Domain Instance properties (see {{prop-interface}} and {{prop-pvd}}). Passive: : The connection will support the use of multiple paths if the remote endpoint requests it. The connection will not actively initiate the use of any new paths, but will accept paths initiated by the remote endpoint.' This mixes two things which should be separated: requesting MP support actively (or just do it if requested by the other end) and opening of new subflows when MP support was negotiated successfully. I thought we wanted to take the later out (opening sub flows) and discuss that separately....?
Just created PR to remove the part about opening new subflows. Do we need to further discuss when/how to open subflows or do we leave this as open for now?
Agree that interim (June 19) to not address opening of subflows in the API

Revised text:
if the chosen transport supports using multiple paths. The connection will negotiate the use of multiple paths if the  <ins> chosen transport supports this. </ins> The connection will support the use of multiple paths if the  <ins> remote endpoint requests it. </ins> The policy for using multiple paths is specified using the separate "multipath-policy" property, see multipath-policy below.  To enable
Original text:
7.5.9. <del> singularTransmission </del>  Boolean false This property specifies that a message should be sent and received as <del> a single packet without transport-layer segmentation or network-layer fragmentation, if possible.  Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError".  When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set. </del>  7.6.

Reviewer comments:
When I initial read the heading I thought this is again about reliability. May we can call this single-segment or something...?
Well it's a term - I don't like it much. Single segment doesn't mean it's all in one IP packet (it means it's all in one transport segment). We could just say sending as a single IP packet.
Interim: proposing to rename to something more simple like Don't Fragment? We don't have a good name.
Don't Fragment seems good too me - and tidy this sentence: OLD: /Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError"./ NEW: /Setting this property causes a "SendError" when an attempt is made to send a message with a size greater than the transport's current estimate of the maximum packet size./

Revised text:
7.5.9.  <ins> noFragmentation </ins> Boolean false This property specifies that a message should be sent and received as  <ins> a single packet network-layer fragmentation, if possible.  Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError".  When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set. </ins> 7.6.
Original text:
4.2.1. Transport Properties are referred to by property names.  These names <del> are lower-case alphanumeric strings in which words may be separated by hyphens.  These names serve two purposes: </del>  Allowing different components of a TAPS implementation to pass Transport Properties, e.g., between a language frontend and a

Reviewer comments:
This doesn't change the idea of translating keywords from the IANA protocol numbers registry to lower-case; it just removes the requirement for all Transport Property Names to be lower-case. Why? Right now, they're camlCase, and I guess that reads better than changing them all into hardtoreadstrings or using-hyphens-everywhere ...

Revised text:
4.2.1. Transport Properties are referred to by property names.  These names  <ins> are alphanumeric strings in which words may be separated by hyphens. These names serve two purposes: </ins> Allowing different components of a TAPS implementation to pass Transport Properties, e.g., between a language frontend and a
Original text:
Since sending a Message may involve a context switch between the application and the transport system, sending patterns that involve multiple small Messages can incur high overhead if each needs to be <del> enqueued separately.  To avoid this, the application should have a way to indicate a batch of Send actions, during which time the implementation will hold off on processing Messages until the batch is complete.  This can also help context switches when enqueuing data in the interface driver if the operation can be batched. </del>  5.2.

Reviewer comments:
In the implementation draft section 5.1.3 says that there should be an interface for the application to indicate batch sending. Section 7.7 specifies such an interface. Should the section in the implementation draft be updated or removed?
I think it should be removed. Mainly, it points out that batching reduces overhead, which is also stated in the API draft in section 7.7.
Perhaps it is still important for the implementation to know that it needs to support batching sends though? I would suggest adjusting the text so it reads from the implementations perspective. Something like
I agree; this is a nice text proposal. PR replaces the current text with your proposed one.

Revised text:
Since sending a Message may involve a context switch between the application and the transport system, sending patterns that involve multiple small Messages can incur high overhead if each needs to be  <ins> enqueued separately.  To avoid this, the application can indicate a batch of Send actions through the API.  When this is used, the implementation should hold off on processing Messages until the batch is complete. </ins> 5.2.
Original text:
4.2.1. <del> Transport Properties are referred to by property names.  These names are alphanumeric strings in which words may be separated by hyphens. These names serve two purposes: </del>  Allowing different components of a TAPS implementation to pass Transport Properties, e.g., between a language frontend and a policy manager, or as a representation of properties retrieved from a file or other storage. <del> Making code of different TAPS implementations look similar. </del>  Transport Property Names are hierarchically organized in the form [<Namespace>.]<PropertyName>. Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- <del> numbers/protocol-numbers.xhtml), translated to lower-case and with characters other than letters, numbers, and hyphens deleted, are reserved for Protocol Specific Properties and MUST not be used for vendor or implementation-specific properties. </del>  4.2.2.

Reviewer comments:
Updates PR to remove reference to lower-case in namespaces corresponding to IANA protocol names. Express that strict adherence to the doc's naming convention is not required, but that symbols in different languages should be visually similar.
NAME NAME Last minute PR

Revised text:
4.2.1.  <ins> Transport Properties are referred to by property names.  For the purposes of this document, these names are alphanumeric strings in which words may be separated by hyphens.  These names serve two purposes: </ins> Allowing different components of a TAPS implementation to pass Transport Properties, e.g., between a language frontend and a policy manager, or as a representation of properties retrieved from a file or other storage.  <ins> Making code of different TAPS implementations look similar.  While individual programming languages may preclude strict adherence to the aforementioned naming convention (for instance, by prohibiting the use of hyphens in symbols), users interacting with multiple implementations will still benefit from the consistency resulting from the use of visually similar symbols. </ins> Transport Property Names are hierarchically organized in the form [<Namespace>.]<PropertyName>. Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol-  <ins> numbers/protocol-numbers.xhtml), reformatted where necessary to conform to an implementation's naming conventions, are reserved for Protocol Specific Properties and MUST not be used for vendor or implementation-specific properties. </ins> 4.2.2.
Original text:
actual thresholds to declare a path unusable are implementation specific. <del> The connection should attempt to use multiple paths in parallel in order to minimize loss and delay.  The actual strategy is implementation specific. </del>  The connection should attempt to use multiple paths in parallel in order to maximize bandwidth and possibly overcome bandwidth

Reviewer comments:
Get a better/more formal explanation of Interactive mode for multipath based on our experience with Siri, etc.
Proposal from Christoph Paasch: The connection should attempt to minimize the latency for interactive traffic patterns by transmitting data across multiple paths. The goal of minimizing the latency will be balanced against the cost fo each of these paths, meaning that depending on the cost of the lower latency path the scheduling might choose to use a higher latency path. Finally, the scheduling of the traffic can be done such that data may be transmitted on multiple paths in parallel to achieve the lowest latency possible.
Thanks for following up on this one.LGTM

Revised text:
actual thresholds to declare a path unusable are implementation specific.  <ins> The connection should attempt to minimize the latency for interactive traffic patterns by transmitting data across multiple paths when it is beneficial to do so.  The goal of minimizing the latency will be balanced against the cost of each of these paths, meaning that depending on the cost of the lower-latency path, the scheduling might choose to use a higher-latency path.  Traffic can be scheduled such that data may be transmitted on multiple paths in parallel to achieve the lowest latency possible.  The specific scheduling algorithm is implementation-specific. </ins> The connection should attempt to use multiple paths in parallel in order to maximize bandwidth and possibly overcome bandwidth
Original text:
5.3. Several protocols allow sending higher-level protocol or application <del> data within the first packet of their protocol establishment, such as TCP Fast Open RFC7413 and TLS 1.3 RFC8446.  This approach is referred to as sending Zero-RTT (0-RTT) data.  This is a desirable property, but poses challenges to an implementation that uses racing during connection establishment. </del>  If the application has 0-RTT data to send in any protocol handshakes, it needs to provide this data before the handshakes have begun.  When

Reviewer comments:
Removed phrasing that implies 0-RTT data is just one packet and added a reference to the Maximum Message Size with Connection Establishment property. Added a sentence on how/when an implementation can set this property.
The opening para reads to me like there is just one first packet. ... or is this actually more than one packets before the handshake complete?
It is one packet for TCP, but it can be more for QUIC, TLS 1.3 (etc)
Reference Connection Property "Maximum Message Size Concurrent with Connection Establishment"
Seems like a useful addition that resolves my issue.

Revised text:
5.3. Several protocols allow sending higher-level protocol or application  <ins> data during their protocol establishment, such as TCP Fast Open RFC7413 and TLS 1.3 RFC8446.  This approach is referred to as sending Zero-RTT (0-RTT) data.  This is a desirable property, but poses challenges to an implementation that uses racing during connection establishment. The amount of data that can be sent as 0-RTT data varies by protocol and can be queried by the application using the "Maximum Message Size Concurrent with Connection Establishment" Connection Property.  An implementation can set this property according to the protocols that it will race based on the given Selection Properties when the application requests to establish a connection. </ins> If the application has 0-RTT data to send in any protocol handshakes, it needs to provide this data before the handshakes have begun.  When
Original text:
use of temporary local addresses, sometimes called "privacy" addresses RFC4941.  Temporary addresses are generally used to prevent linking connections over time when a stable address, sometimes called <del> "permanent" address, is not needed.  Note that if an application Requires the use of temporary addresses, the resulting Connection cannot use IPv4, because temporary addresses do not exist in IPv4. </del>  5.2.13.

Reviewer comments:
NAME PTAL
sec 5.2.12 Using temporary local addresses may break various mechanisms that prove address ownership (e.g QUIC resumption tokens) and therefore impair performance as the client has to re-verify its address.
The default is to use a temporary address for client local address; and to not use it for a server local address. This is the same as most socket APIs. What are you suggesting in the text, NAME
right, a QUIC resumption token will generally contain the client's IP address so that future connections no longer have to go through Retry and anti-amplification mechanisms, which reduce throughput. so IIUC 5.2.12 could say something like "Clients that use temporary local addresses might invalidate server-provided tokens that validate the client's IP addresses (e.g. Sec 8.1.3 of quic-transport), increasing latency."
Add a one-sentence warning that using a temporary address has a potential performance impact on resumption.
Do we wish to refer to RFC 7721?
This looks pretty close ... check these words and submit.

Revised text:
use of temporary local addresses, sometimes called "privacy" addresses RFC4941.  Temporary addresses are generally used to prevent linking connections over time when a stable address, sometimes called  <ins> "permanent" address, is not needed.  There are some caveats to note when specifying this property.  First, if an application Requires the use of temporary addresses, the resulting Connection cannot use IPv4, because temporary addresses do not exist in IPv4.  Second, temporary local addresses might involve trading off privacy for performance. For instance, temporary addresses can interfere with resumption mechanisms that some protocols rely on to reduce initial latency. </ins> 5.2.13.
Original text:
Preference is of type Boolean, with "true" indicating that the Selection Property has been applied.  For types Integer and Numeric, special values can be defined per property; it is up to implementations how these special values are represented (e.g., by using -1 for an otherwise non-negative value). interface <del> Set (Preference, Enumeration) </del>  <del> Empty set (not setting a preference for any interface) </del>  This property allows the application to select any specific network interfaces or categories of interfaces it wants to "Require", pvd <del> Set (Preference, Enumeration) </del>  <del> Empty set (not setting a preference for any PvD) </del>  Similar to interface instances and types (see prop-interface), this property allows the application to control path selection by underlying transport security protocols.  When not specified, these algorithms should use known and safe defaults for the system.  Parameters include: ciphersuites, supported groups, and <del> signature algorithms. </del>  Pre-Shared Key import: Used to install pre-shared keying material established out-of-band.  Each pre-shared keying material is

Reviewer comments:
I should have said: I approve this, modulo the changes requested by NAME
Thanks for incorporating my suggested changes. I think this can be merged now.

Revised text:
Preference is of type Boolean, with "true" indicating that the Selection Property has been applied. <ins> Tuple: An ordered grouping of multiple value types.  In this this document, it is written as a list in brackets, e.g., "(Enumeration, Preference)" The composition of types and their order depends on the property and is fixed for the property.  The actual representation is implementation-dependent. Collection: An unordered grouping of one or more values of the same type.  The actual representation, e.g. as a set or an array, is implementation-dependent. </ins> For types Integer and Numeric, special values can be defined per property; it is up to implementations how these special values are represented (e.g., by using -1 for an otherwise non-negative value). interface  <ins> Collection of (Preference, Enumeration) </ins>  <ins> Empty (not setting a preference for any interface) </ins> This property allows the application to select any specific network interfaces or categories of interfaces it wants to "Require", pvd  <ins> Collection of (Preference, Enumeration) </ins>  <ins> Empty (not setting a preference for any PvD) </ins> Similar to interface instances and types (see prop-interface), this property allows the application to control path selection by underlying transport security protocols.  When not specified, these algorithms should use known and safe defaults for the system.  Parameters include: ciphersuites, supported groups, and  <ins> signature algorithms.  These parameters take a collection of supported algorithms as parameter. </ins> Pre-Shared Key import: Used to install pre-shared keying material established out-of-band.  Each pre-shared keying material is
Original text:
The transport services API resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a <del> Connection.  The API explicitly does not require the application to resolve names, though there is a tradeoff between early and late binding of addresses to names.  Early binding allows the API implementation to reduce connection setup latency, at the cost of potentially limited scope for alternate path discovery during Connection establishment, as well as potential additional information leakage about application interest when used with a resolution method (such as DNS without TLS) which does not protect query confidentiality. </del>  The Resolve() action on Preconnection can be used by the application to force early binding when required, for example with some Network and fallback or re-establishment is supported in the transport system.  These communication activities are not different from what is used today.  However, the goal of a TAPS transport system is to support such mechanisms as a generic service within the transport layer.

Reviewer comments:
I would reword this text in §5.1: such that the tradeoff is listed in a (new) privacy considerations section, leaving the description of the reduced connection setup latency in early binding here as a functional justification.
LGTM (note: accept 1 nit fix before pressing Merge)

Revised text:
The transport services API resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a  <ins> Connection.  Privacy considerations for the timing of this resolution are given in privacy-security. </ins> The Resolve() action on Preconnection can be used by the application to force early binding when required, for example with some Network and fallback or re-establishment is supported in the transport system. <ins> The interface explicitly does not require the application to resolve names, though there is a tradeoff between early and late binding of addresses to names.  Early binding allows the API implementation to reduce connection setup latency, at the cost of potentially limited scope for alternate path discovery during Connection establishment, as well as potential additional information leakage about application interest when used with a resolution method (such as DNS without TLS) which does not protect query confidentiality. </ins> These communication activities are not different from what is used today.  However, the goal of a TAPS transport system is to support such mechanisms as a generic service within the transport layer.