Change:
assumed to be ordered within the Message.  If an application does not care about the order in which a peer receives two distinct spans of bytes, those spans of bytes are considered independent <del> Messages.  Messages may or may not be usable if incomplete or corrupted.  Boundaries of a Message may or may not be understood or transmitted by transport protocols.  Specifically, what one application considers to be two Messages sent on a stream-based transport may be treated as a single Message by the application on the other side. Send is the action to transmit a Message or partial Message over a </del> <ins> Messages.  If a received Message is incomplete or corrupted, it may or may not be usable by certain applications.  Boundaries of a Message may or may not be understood or transmitted by transport protocols.  Specifically, what one application considers to be two Messages sent on a stream-based transport may be treated as a single Message by the application on the other side. Send: The action to transmit a Message or partial Message over a </ins> Connection to a Remote Endpoint.  The interface to Send may include options specific to how the Message's content is to be sent.  Status of the Send operation may be delivered back to the application in an event (events). <del> Receive is an action that indicates that the application is ready to asynchronously accept a Message over a Connection from a Remote </del> <ins> Receive: An action that indicates that the application is ready to asynchronously accept a Message over a Connection from a Remote </ins> Endpoint, while the Message content itself will be delivered in an event (events).  The interface to Receive may include options specific to the Message that is to be delivered to the

Discussion:
Integrate Gorry's comments from This does not yet address Gorry's two other issues, which cover the background section, or potentially moving the transport implementation earlier in the document.
These issues mostly relate to the ARCH document wording: Section: Introduction It looks to me like we should have a reference after:/the BSD socket() interface./ Section: Background. > Section: Transport Services Architecture and Concepts The Application box seems one character wider than the TAPS boxes. i know apps are important to APIs, but suspect this is just a typo with extra '-' characters! /primarily offer knobs that are applicable to multiple transports/ Understand /knobs/, but suspect someone who does not speak English as a first language could be most puzzled, can we use a different word please? This may be something: /by which data transmission is ceased/ To me this doesn't read as common English and would be: /by which data transmission is stopped/ /by which data transmission ceases/ /Endpoint can vary in levels of specificity/ /Endpoint/ and /vary..specificity/ ... does it really vary, this seems difficult to pin down. Is this better as: /An Endpoint may be specified at various levels/? /that it wants to use for transport connections/ ... surely it does use it, or is more intended (if so, what)? Is it simpler as: /that it uses for transport connections/ /paths between itself and the Remote Endpoint/ I think strictly speaking, it is not between the App and the remote endpoint, but the local and remote endpoints, so could I suggest: /paths between the Local Endpoint and the Remote Endpoint/ /These options can come in the form of / could this be written: /These options can take the form of / -- appears multiple times in the ID. /Examples of options which may influence/ should be: /Examples of options that may influence/ /but that if this protocol is employed, a particular set of options should be used./ understood, is it even clearer (or not) as: /but that if this protocol is employed, a particular set of options should then be used./ In Section: Establishment Actions and Data Transfer Objects and Actions and Termination Actions:: I read this as definitions of terms, but there is no syntax that helps someone understand this.

Would it look foolish to include a colon or something after each term (as for the case currently defining message), so it is super clear that this is the defining para? In Section: Establishment Actions /Connection to a remote endpoint/ Could remote endpoint be capitalised here to be consistent with earlier? /for example, to a TCP simultaneous open./ do we need an info reference here. (Sadly, many people will not know what this is). In Section: Data Transfer Objects and Actions / Messages may or may not be usable if incomplete or corrupted. / Agree, but not entirely clear, so I think we should explain to the reader. Could we say: /If a received Message is incomplete or corrupted, it may or may not be usable by a specific application./ In Section: Transport System Implementation Concepts /the functionality of transport networking/ what is transport networking? - either define or rephrase, e.g. as: /the functionality required to provide a transport service across a network/ In Section: Connection Group: /Connection Group: A Connections Group/ mixed single and plural, suggest: /Connection Group: A Connection Group/ /Path: A Path represents an available set of properties of a network route on which packets may be sent or received./ I'm not so happy with this. I know people use terms in various ways but to me this is not a route. I'd prefer something like: /Path: A Path represents an available set of properties that a Local Endpoint may use to send or receive packets with a Remote Endpoint./ I think we need to define /candidate/ in some way, e.g. something like: a path or protocol identified in the gathering stage over which a connection may be attempted in the racing stage/. Also I'd much prefer to actually the two terms (as we currently do in the earlier figure): /Candidate Gathering/ and /Candidate Racing/ The present contents of, provides a set of definitions which are fine... /Transport System Implementation Concepts/ but I really wonder if I could suggest something slightly different. I wonder if we could call this /Transport System Concepts/ and move this way forward in the document to provide a nice early introduction of these terms (with forward refs to sections where these are discussed - if that appeals.

Things I'd like to see in this section: /Transport System Implementation Concepts/ Can we add a couple of sentences on gathering and racing, just to explain this using the terms used in the /lifetime of a connection/ figure. Can we create small subsections on /Cached State/ and /System Policy/ I think the subsection section titles below should be changed: /Gathering//Candidate Gathering/ and /Candidate Racing/Candidate Racing/ /### Message Framing, Parsing, and Serialization {#framing}/ This subsection appears out-of sequence. (Actually this could really help the reader if made a little easier to read and placed ahead of discussing the details). >
Closing this, we can discuss details in PR
lgtm