Change:
The most basic mapping for sending a Message is an abstraction of datagrams, in which the transport protocol naturally deals in <del> discrete packets.  Each Message here corresponds to a single datagram.  Generally, these will be short enough that sending and receiving will always use a complete Message. </del> <ins> discrete packets (such as UDP).  Each Message here corresponds to a single datagram.  Generally, these will be short enough that sending and receiving will always use a complete Message. </ins> <del> For protocols that expose byte-streams, the only delineation provided by the protocol is the end of the stream in a given direction.  Each Message in this case corresponds to the entire stream of bytes in a direction.  These Messages may be quite long, in which case they can be sent in multiple parts. </del> <ins> For protocols that expose byte-streams (such as TCP), the only delineation provided by the protocol is the end of the stream in a given direction.  Each Message in this case corresponds to the entire stream of bytes in a direction.  These Messages may be quite long, in which case they can be sent in multiple parts. </ins> Protocols that provide the framing (such as length-value protocols, <del> or protocols that use delimiters) may support Message sizes that do not fit within a single datagram.  Each Message for framing protocols corresponds to a single frame, which may be sent either as a complete Message in the underlying protocol, or in multiple parts. </del> <ins> or protocols that use delimiters like HTTP/1.1) may support Message sizes that do not fit within a single datagram.  Each Message for framing protocols corresponds to a single frame, which may be sent either as a complete Message in the underlying protocol, or in multiple parts. </ins> 5.1.

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?