Change:
connection. If the application has 0-RTT data to send during handshake(s), it <del> needs to provide this data before the handshakes have begun.  When racing, this means that the data should be provided before the process of connection establishment has begun.  If the application wants to send 0-RTT data, it must indicate this to the implementation by setting the "Safely Replayable" send parameter to true when sending the data.  In general, 0-RTT data may be replayed (for example, if a TCP SYN contains data, and the SYN is retransmitted, the data will be retransmitted as well but may be considered as a new connection instead of a retransmission).  Also, when racing connections, different leaf nodes have the opportunity to send the same data independently.  If data is truly safely replayable, this should be permissible. </del> <ins> needs to provide this data before the handshakes have begun.  If the application wants to send 0-RTT data, it must indicate this to the implementation by setting the "Safely Replayable" send parameter to true when sending the data.  In general, 0-RTT data may be replayed (for example, if a TCP SYN contains data, and the SYN is retransmitted, the data will be retransmitted as well but may be considered as a new connection instead of a retransmission).  When racing connections, different leaf nodes have the opportunity to send the same data independently.  If data is truly safely replayable, this is permissible. </ins> Once the application has provided its 0-RTT data, a Transport Services implementation should keep a copy of this data and provide

Discussion:
NB: This reviewer may be unreasonably biased against unnecessary mention of event-driven interaction patterns. Viewed in concert with the other pre-requisite TAPS documents, the text of this draft is quite readable and represents a useful collection of implementation considerations for various components of a transport services system. My biggest point of concern is the fluctuating level of detail between the different Sections, leading to speculations about who might have written what. Some Sections remain quite general and avoid making too many assumptions about the underlying software architecture. Others discuss a specific implementation approach in some detail. In particular Section 6 (Message Framers) stands out from the rest of the text. Language that relates to event-driven interaction patterns is almost exclusively found in this Section, where different types of events are "generated", "delivered", "received" or "handled" by and between various components. In the rare cases where events are mentioned in the other Sections, they are often associated with other verbs like "notify", "cause", "provoke" or even "call" (see, e.g., Section 4.5 or Section 8). Indeed, the text in most of these other Sections would require only very minor edits to avoid any reference to an event-driven architecture altogether (examples below). It is interesting that the same can not easily be said of Section 6, alone. Overall, the text could benefit from an edit pass that normalizes language and (use of) terms and adds a few more references to related documents. Other than that, I have few issues with it. Below are a few remarks and suggestions to cherry-pick from, as usual. Quoting from 4.4.1. Determining Successful Establishment: Not only is the term "Ready event" used without any sort of context or introduction, it is the first point in the text where familiarity with a specific event type is implied. The intent of the whole sentence could be much better conveyed without this terminological baggage. Suggestion: From later in the section, quoting: While it is reasonable to mention the specific error type here (although a reference to the document where it is defined is still missing), wouldn't the following suffice? Quoting from 4.5. Establishing multiplexed connections: Shouldn't events rather be "emitted" or "triggered" instead of (ambiguously) "called"?

It is gratifying to observe that Sections 4.6 and 4.7 on the other hand entirely avoid specific references to an event-based architecture, instead speaking of, e.g., "passing" Connection objects to the application. Quoting from 6. Implementing Message Framers: Given that this section is the only place in the text where concepts and language centered around an event-based implementation are consistently used, it would be appropriate to point this out in its introduction: Quoting 4.4.1. Determining Successful Establishment: The adverb "differently" is too far removed from "select", becoming ambiguous and could be wrongly understood to modify "connected" instead. Suggestion: Quoting 4.6. Handling connectionless protocols: The reference to the section is ungrammatical. About 5. Implementing Sending and Receiving Data: Might it not be helpful to conclude the introduction with some examples: UDP Datagrams, TCP streams, HTTP responses? About 5.1.1. Message Properties: The list of Message Properties is given without any sort of context or introduction. What's the story here, is this an exhaustive list or just a list of those properties that can be adjusted to modify the send and receive behavior? Quoting 5.2. Sending Messages: That sentence is exceedingly hard to parse. Quoting 5.3. Handling of data for fast-open protocols: Possibly intentional redundant wording, but unfortunately distracting.
LGMTThanks for taking care of the edits! Just added a nit and a question. I assume you deliberately skipped the comment from the issue about event-based terminology in Section 6, not thinking it was needed as we reference the API draft for the terminology?