Change:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.

Discussion:
receive Events (see receive-events), the application can query information about the local and Remote Endpoint: <del> Message Contexts can also be used to send messages in reply to other messages, see send-replies for details. </del> 8.1.2. Although most applications communicate over a network using well-

8.2.2. <del> When a message is sent in response to a message received, the application can use the Message Context of the received Message to construct a Message Context for the reply. By using the "replyMessageContext", the transport system is informed that the message to be sent is a response and can map the response to the same underlying transport connection or the stream from which the request was received.  The concept of Message Contexts is described in msg-ctx. 8.2.3. </del> Like all Actions in this interface, the Send Action is asynchronous. There are several Events that can be delivered in response to Sending a Message.  Exactly one Event (Sent, Expired, or SendError) will be

Action resulted in a particular Send Event.  The manner in which this correlation is indicated is implementation-specific. <del> 8.2.3.1. </del> <ins> 8.2.2.1. </ins> The Sent Event occurs when a previous Send Action has completed, i.e., when the data derived from the Message has been passed down or

that always waits for the Sent Event before calling the next Send Action. <del> 8.2.3.2. </del> <ins> 8.2.2.2. </ins> The Expired Event occurs when a previous Send Action expired before completion; i.e. when the Message was not sent before its Lifetime

Expired Event contains a reference to the Message to which it applies. <del> 8.2.3.3. </del> <ins> 8.2.2.3. </ins> A SendError occurs when a Message was not sent due to an error condition: an attempt to send a Message which is too large for the

the Connection's transport properties.  The SendError contains a reference to the Message to which it applies. <del> 8.2.4. </del> <ins> 8.2.3. </ins> It is not always possible for an application to send all data associated with a Message in a single Send Action.  The Message data

belonging to the same Message, and will constitute an in-order series until the endOfMessage is marked. <del> 8.2.5. </del> <ins> 8.2.4. </ins> To reduce the overhead of sending multiple small Messages on a Connection, the application could batch several Send Actions

The semantics for starting and ending a batch can be implementation- specific, but need to allow multiple Send Actions to be enqueued. <del> 8.2.6. </del> <ins> 8.2.5. </ins> For application-layer protocols where the Connection initiator also sends the first message, the InitiateWithSend() action combines

will not result in a SendError separate from the InitiateError signaling the failure of Connection establishment. <del> 8.2.7. </del> <ins> 8.2.6. </ins> The Transport Services interface provides two properties to allow a sender to signal the relative priority of data transmission: the