jiebi/TextFlow huggingface dataset:
Original text:
MessagContext on the messages received (see msg-ctx for further details).  Calling Rendezvous() on a Preconnection with an any-source multicast group address as the Remote Endpoint will join the multicast group, and also indicates that the resulting connection can be used to send Rendezvous() on a Preconnection with a source-specific multicast group address as the Local Endpoint results in an EstablishmentError.  See multicast-examples for more examples. 6.1.2.

Reviewer comments:
Fix-up multicast
Fixing the sequence of some examples vs. the text describing them, and referring to examples ("The following API calls can be used ...")
Also a great PR! :) Seriously, thanks!

Revised text:
MessagContext on the messages received (see msg-ctx for further details). <ins> The following API calls can be used to configure a Preconnection before calling Listen(): </ins> Calling Rendezvous() on a Preconnection with an any-source multicast group address as the Remote Endpoint will join the multicast group, and also indicates that the resulting connection can be used to send Rendezvous() on a Preconnection with a source-specific multicast group address as the Local Endpoint results in an EstablishmentError. <ins> The following API calls can be used to configure a Preconnection before calling Rendezvous(): </ins> See multicast-examples for more examples. 6.1.2.
Original text:
Numeric (non-negative) or "Disabled" <del> Implementation-defined </del>  A Transport Services API can request a protocol that supports sending keep alive packets keep-alive.  If this property is Numeric, it

Reviewer comments:
URL we have two types... but the default is Implementation-defined. Implementation-defined type is never defined or described. This needs to be fixed.

Revised text:
Numeric (non-negative) or "Disabled"  <ins> "Disabled" </ins> A Transport Services API can request a protocol that supports sending keep alive packets keep-alive.  If this property is Numeric, it
Original text:
process of identifying options for connecting, such as resolution of the Remote Endpoint, occurs in response to the Initiate call. <del> Listen: Enables a listener to accept incoming Connections.  The </del>  Listener will then create Connection objects as incoming connections are accepted (events).  Listeners by default register with multiple paths, protocols, and Local Endpoints, unless

Reviewer comments:
URL The use of Cap 'C' in the first sentence for connection is confusing. The Connection object is created after the incoming connections are accepted. The Cap C makes it assume that it not that case and create an expectation that the remote is also a TAPS implementation.

Revised text:
process of identifying options for connecting, such as resolution of the Remote Endpoint, occurs in response to the Initiate call.  <ins> Listen: Enables a listener to accept incoming connections.  The </ins> Listener will then create Connection objects as incoming connections are accepted (events).  Listeners by default register with multiple paths, protocols, and Local Endpoints, unless
Original text:
set of allowable protocol features without changing the core implementation.  3.3. A Transport Services implementation can select Protocol Stacks based

Reviewer comments:
URL If an application wishes to use a special feature then if might need to adjust itself if that special feature is not applicable to the Connection Object it gets/ gets created for. Should there be no requirement(at least recommendation) on getting this information back? The application can ask a specialized feature in a way that it gets what it wants or the communication MUST fail. In such case the should be a requirement on the application to be specific about it or?
The API solves this in two ways: We have a preference-type that allows the application to explicitly state that it requires/prefers/does-not-care/wants-to-avoid/prohibits each feature. After the establishment, the application can query each feature and gets a boolean back whether it is present or not. Should we add this as a forward reference here or at least hint at the solution?
Hint at the solution sounds like a very good approach to me.

Revised text:
set of allowable protocol features without changing the core implementation. <ins> To control these specialized features, the application can declare its preference - whether the presence of a specific feature is prohibited, should be avoided, can be ignored, is preferred, or is required in the Pre-Establishment phase.  An implementation of a Transport Services API would honor this preference and allow the application to query the availability of each specialized feature after a successful establishment. </ins> 3.3. A Transport Services implementation can select Protocol Stacks based
Original text:
3.3. <del> A Transport Services implementation can select Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any security parameters.  If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent".  Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. </del>  The following two examples show non-equivalent Protocol Stacks:

Reviewer comments:
URL Here it seems we are defining "equivalent" twice. I would rather write - >Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. and the equivalent stacks can be swapped or raced. Also in the example - it is not clear that swapping and racing in important, however, application provided properties are. Apart from this I also think the title and content is mismatching. I found the last paragraph talking about swapping and racing focusing on security. Here we are imposing requirements on swapping and racing. These are very important for the security consideration and to me should get its own title and section separated from selection of equivalence.
LGTM!Looks good

Revised text:
3.3.  <ins> A Transport Services implementation can attempt and select between multiple Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any security parameters.  The implementation can only attempt to use multiple Protocol Stacks when they are "equivalent", which means that the stacks can provide the same Transport Properties and interface expectations as requested by the application.  Equivalent Protocol Stacks can be safely swapped or raced in parallel (see racing) during connection establishment. </ins> The following two examples show non-equivalent Protocol Stacks:
Original text:
This approach is commonly used for connections with optional proxy server configurations.  A single connection might have several options available: an HTTP-based proxy, a SOCKS-based proxy, or no <del> proxy.  These options should be ranked and attempted in succession. </del>  This approach also allows a client to attempt different sets of application and transport protocols that, when available, could

Reviewer comments:
URL I think we should add a similar ranking consideration description as we have for Network paths. Otherwise, I am not sure how to rank the protocol option.
I think here as well that the options should be ranked based on preference, system policy, and performance. I made a pull request to add it.
LGTM, lets of others have any opinion about it..
I agree with NAME
WFM

Revised text:
This approach is commonly used for connections with optional proxy server configurations.  A single connection might have several options available: an HTTP-based proxy, a SOCKS-based proxy, or no  <ins> proxy.  As above, these options should be ranked based on preference, system policy, and performance and attempted in succession. </ins> This approach also allows a client to attempt different sets of application and transport protocols that, when available, could
Original text:
"WithIPv6Address" with an unscoped address and "WithInterface " together. <del> An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </del>  The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a

Reviewer comments:
I'm happy to do this! But while we're at it, isn't the "a" a bit awkward? Wouldn't this read even better as: "An Endpoint MUST NOT be configured with multiple identifiers of the same type." I just pushed that suggestion.
URL This seems to me as a strong claim without using normative language. Shall we use normative language here?
Agree, although then I think we need to explain "set" so that we create an RFC2119 sentence with meaning when read on its own. Is this anywhere near: An Endpoint MUST NOT set multiple identifiers of the same type. And... is the /that is/ correct? or is this an example of something that is not allowed?
I'd say it's an example, although also the most likely such case. Suggest: replace "That is," with "Thus,"
If this is just an example then lets just be explicit about it.
I like the change. Is the English clunky, could it be: An Endpoint MUST NOT be configured with multiple identifiers of a same type.

Revised text:
"WithIPv6Address" with an unscoped address and "WithInterface " together.  <ins> An Endpoint MUST NOT be configured with multiple identifiers of the same type.  For example, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </ins> The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a
Original text:
updating maintenance options. Termination (termination) focuses on the methods by which data <del> transmission is stopped, and state is torn down in the transport. </del>  The diagram below provides a high-level view of the actions and events during the lifetime of a Connection object.  Note that some

Reviewer comments:
/transport/ should be /connection state/
This resolves one small part of Zahed's review.
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM

Revised text:
updating maintenance options. Termination (termination) focuses on the methods by which data  <ins> transmission is stopped, and connection state is torn down. </ins> The diagram below provides a high-level view of the actions and events during the lifetime of a Connection object.  Note that some
Original text:
the Remote Endpoint if the transport protocol allows this.  (Note that this is distinct from the concept of "half-closing" a bidirectional connection, such as when a FIN is sent in one <del> direction of a TCP connection ?RFC9293.  The end of a stream can </del>  also be indicated using Message Properties when sending.) Abort: The action the application takes on a Connection to

Reviewer comments:
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM

Revised text:
the Remote Endpoint if the transport protocol allows this.  (Note that this is distinct from the concept of "half-closing" a bidirectional connection, such as when a FIN is sent in one  <ins> direction of a TCP connection RFC9293.  The end of a stream can </ins> also be indicated using Message Properties when sending.) Abort: The action the application takes on a Connection to
Original text:
choosing the candidates to be raced, selecting appropriate transport parameters, etc.  An application SHOULD NOT depend on specific caching behaviour, instead it ought to explicitly request <del> any requid or desired properties via the Transport Services API. </del>  4.2.1.

Reviewer comments:
Don't just rely on the cache .
URL I think we should be very specific that the application SHOULD not expect certain caching behavior or MAY expect a minimum set of information cached. This is also related to the expectancy from application to expect same protocol given same properties and security parameter each time. will such input generate same consistent out put from one TAPS system?
I suggest adding this explicitly - something like: This caching does not imply that the same decisions are necessarily made for subsequent connections, rather, it means that cached state is used by the Transport Services architecture to inform functions such as choosing the candidates to be raced, selecting appropriate transport parameters, etc.
See PR on request required properties , which could close this issue.
Thought resolved by merged PR in latest editor version.
NAME Does the merged text in master address issue ?
LGTM, Thansk.
Very nice (IMHO)!

Revised text:
choosing the candidates to be raced, selecting appropriate transport parameters, etc.  An application SHOULD NOT depend on specific caching behaviour, instead it ought to explicitly request  <ins> any required or desired properties via the Transport Services API. </ins> 4.2.1.
Original text:
notified of the status of its data transfer. Event Handling (events) defines categories of notifications that <del> an application can receive during the lifetime of transport objects.  Events also provide opportunities for the application to interact with the underlying transport by querying state or updating maintenance options. </del>  Termination (termination) focuses on the methods by which data transmission is stopped, and connection state is torn down.

Reviewer comments:
Responding to review and tighter wording for the Arch draft: Undefined "transport object"
URL Where is this transport object defined?

Revised text:
notified of the status of its data transfer. Event Handling (events) defines categories of notifications that  <ins> an application can receive during the lifetime of a Connection. Events also provide opportunities for the application to interact with the underlying transport by querying state or updating maintenance options. </ins> Termination (termination) focuses on the methods by which data transmission is stopped, and connection state is torn down.
Original text:
identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: endpoint, path (labeled here <del> by interface), and protocol.  The above example can now be written more succinctly as: </del>  When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer

Reviewer comments:
Fixes Issue
URL We have given example but we haven't really defined how the format should be written or how one should interpret in the example. Here "Any Stream" means any protocol that supports streaming ... but it would take quit some time to get to that point . It is also confusing that an "Any" is used with comma (,) and another is without a comma... To understand the example correctly, I suggest we either keep the examples on to a level where this is already described or describe how we are formatting the expression in this document as we described tree structure with numeric ( for example 1 , 1,1 ).
Perhaps we can just write HTTP and Stream without the Any part? Alternatively we could add a specific interface, e.g Wi-Fi, to avoid the first Any. And then also clarify the description of the example and what is raced. The notation is described earlier in the text, so I assume that is not the problem?
If you propose the changes then I can perhaps understand it better about the modified example.
NAME does PR solve the issue for you?
Thanks for the PR. I put two comments as input. I am fine merging it once Tommy's questions are resolved.

Revised text:
identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: endpoint, path (labeled here  <ins> by interface), and protocol.  In protocol stacks, the layers are separated by '/' and ordered top-down.  The above example can now be written more succinctly as: </ins> When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer
Original text:
4.1.8. <del> A Connection Group is a set of Connections that shares properties and caches.  A Connection Group represents state for managing Connections within a single application, and does not require end-to-end protocol signaling.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together. </del>  The API allows a Connection to be created from another Connection. This adds the new Connection to the Connection Group.  A change to of an already active multi-streaming protocol instance. While Connection Groups are managed by the Transport Services system, <del> an application can define Connection Contexts to control caching boundaries, as discussed in conn-context. </del>  4.2.

Reviewer comments:
URL In this section - can we be clear on stating what properties we are taking about and what the caches. see the first line of the section. the second paragraph should at least mention why the connection is cloned. We haven't introduced the cloning before. we need to discuss the relation with Connection Context, does a Connection group have same connection context? My current understanding is if the Connection Context is separate then those Connections wont be grouped. But I fear that this can create confusion.
Latest merged master fixes bullet 2. The others need new text.
LGTM! Many thanks for doing this

Revised text:
4.1.8.  <ins> A Connection Group is a set of Connections that shares Connection Properties and cached state generated by protocols.  A Connection Group represents state for managing Connections within a single application, and does not require end-to-end protocol signaling.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together. </ins> The API allows a Connection to be created from another Connection. This adds the new Connection to the Connection Group.  A change to of an already active multi-streaming protocol instance. While Connection Groups are managed by the Transport Services system,  <ins> an application can define different Connection Contexts for different Connection Groups to explicitly control caching boundaries, as discussed in conn-context. </ins> 4.2.
Original text:
secure protocols to insecure protocols, or to weaker versions of secure protocols (see equivalence).  For example, if an application requests a specific version of TLS, but the desired version of TLS is <del> not available, its connection will fail.  The Transport Services API MAY allow applications to specify minimum versions that are allowed to be used by the Transport Services system. </del> 

Reviewer comments:
URL This I believe is already covered in section 3.3. URL why this should not be moved to section 3.3 ?
Any thoughts here?
We did this intentionally to make sure the security considerations had the normative language there. I personally find it OK to have it both places. NAME are you OK with no change?
(We could of course note in one sentence that the requirements for security are provided in the security considerations section).
I added a reference back to 3.3, and made the MAY be a can. So that takes care of the second point. However, the first point with the cert reference I don't think is covered in 3.3, and should remain in security.
NAME
seems like I missed all the call out for me.. this has been strange that I don't get any emails about my mentions and comment's reply. This is only happening in case of TAPS github. anyway, changes are OK with me.
WFMlgtm

Revised text:
secure protocols to insecure protocols, or to weaker versions of secure protocols (see equivalence).  For example, if an application requests a specific version of TLS, but the desired version of TLS is  <ins> not available, its connection will fail.  As described in equivalence, the Transport Services API can allow applications to specify minimum versions that are allowed to be used by the Transport Services system. </ins>