Original text:
TCP, this may correspond to when the data has entered the send buffer.  5.1.2. Similar to sending, Receiving a Message is determined by the top- 7.2.  Sender-side framing allows a caller to provide the interface with a function that takes a Message of an appropriate application-layer type and returns an array of octets, the on-the-wire representation

Reviewer comments:
See issue The one question I have here is the semantics around batching. In our implementation, we use block semantics (from clang), to batch looks like: connectionbatch(^{ connectionsend(...); connection_send(...); }); where the block is called inline, and the batch is over when the block returns. I'm not sure what the right style for the pseudo-code is for the draft.
In aligning the implementation with the API for the initial draft, we removed this text since we still need text in the API: Since sending a Message may involve a context switch between the application and the transport system, sending patterns that involve multiple small Messages can incur high overhead if each needs to be enqueued separately. To avoid this, the application should have a way to indicate a batch of Send actions, during which time the implementation will hold off on processing Messages until the batch is complete. This can also help context switches when enqueuing data in the interface driver if the operation can be batched.
This seems equivalent to the idea of PUSH in existing systems and would make sense for lots of short write calls.
+1. The higher-level question here is how to support high-performance applications. Send batching is one thing you can do here. Receive batching would be another obvious one. Zero-copy is another, though that's probably so tied to implementation and platform that it's not useful to standardize. But there should be some way for this interface to coexist with it...
+1 from me too
+1 In my opinion, support for high-performance applications is nothing we can add to the API, but rather something we must sure to not prevent or make hard to implement. So we should ask ourselves for every point in the API "can this be implemented zero-copy" or "can an implementation batch this" – if the answer is no, we have to fix that.
this one seems to have consensus and does not seem to be too much work. NAME if you can get a PR in in the next week or so let's ship it with ietf-00...
I'll try to get this in soon!
fixed with merge of
LGTM, we can worry about the right way to pseudocode this later.

Revised text:
TCP, this may correspond to when the data has entered the send buffer. <ins> 5.1.1.3. Since sending a Message may involve a context switch between the application and the transport system, sending patterns that involve multiple small Messages can incur high overhead if each needs to be enqueued separately.  To avoid this, the application should have a way to indicate a batch of Send actions, during which time the implementation will hold off on processing Messages until the batch is complete.  This can also help context switches when enqueuing data in the interface driver if the operation can be batched. </ins> 5.1.2. Similar to sending, Receiving a Message is determined by the top- 7.2. <ins> In order to reduce the overhead of sending multiple small Messages on a Connection, the application may want to batch several Send actions together.  This provides a hint to the system that the sending of these Messages should be coalesced when possible, and that sending any of the batched Messages may be delayed until the last Message in the batch is enqueued. 7.3. </ins> Sender-side framing allows a caller to provide the interface with a function that takes a Message of an appropriate application-layer type and returns an array of octets, the on-the-wire representation