Code change:
Remote Endpoint and the Local Endpoint, such as IP addresses resolved from a DNS hostname. <ins> 4.2.3. While some transports expose a byte stream abstraction, most higher level protocols impose some structure onto that byte stream.  That is, the higher level protocol operates in terms of messages, protocol data units (PDUs), rather than using unstructured sequences of bytes, with each message being processed in turn.  Protocols are specified in terms of state machines acting on semantic messages, with parsing the byte stream into messages being a necessary annoyance, rather than a semantic concern.  Accordingly, the Transport Services architecture exposes messages as the primary abstraction.  Protocols that deal only in byte streams, such as TCP, represent their data in each direction as a single, long message.  When framing protocols are placed on top of byte streams, the messages used in the API represent the framed messages within the stream. Providing a message-based abstraction also provides: the ability to associate deadlines with messages, for transports that care about timing; the ability to provide control of reliability, choosing what messages to retransmit in the event of packet loss, and how best to make use of the data that arrived; the ability to manage dependencies between messages, when some messages may not be delivered due to either packet loss or missing a deadline, in particular the ability to avoid (re-)sending data that relies on a previous transmission that was never received. All require explicit message boundaries, and application-level framing of messages, to be effective.  Once a message is passed to the transport, it can not be cancelled or paused, but prioritization as well as lifetime and retransmission management will provide the protocol stack with all needed information to send the messages as quickly as possible without blocking transmission unnecessarily.  The transport services architecture facilitates this by handling messages, with known identity (sequence numbers, in the simple case), lifetimes, niceness, and antecedents. Transport protocols such as SCTP provide a message-oriented API that has similar features to those we describe.  Other transports, such as TCP, do not.  To support a message oriented API, while still being compatible with stream-based transport protocols, implementations of the transport services architecture should provide APIs for framing and de-framing messages.  That is, we push message framing down into the transport services API, allowing applications to send and receive complete messages.  This is backwards compatible with existing protocols and APIs, since the wire format of messages does not change, but gives the protocol stack additional information to allow it to make better use of modern transport services. </ins> 5. RFC-EDITOR: Please remove this section before publication.

Related discussion:
text: This is a reworking of the text from Section 4.2 of draft-trammell-taps-post-sockets-03, intended to help motivate the choice of Message-based APIs with framing for the transport services architecture. The level of detail here seems appropriate for the architecture document, rather than the API.
Well written, NAME
What's convenient about the framer? If I have messages of 100 bytes and the length is what defines my message, what's the point of requiring me to define a framer function that I give to the system? I just send, send, send, off go 3 100-byte messages. Hard to get more convenient than that :) I understand that the hook to a sender-side and receiver-side framer can allow you to offer a library that does framing when needed; I don't personally see this as a big win, but okay... and I understand that forcing apps to use a receiver side de-framer can, in principle, let us do cool things on the receiver side (accessing messages out of the bytestream). But for sending this just seems to be an uncomfortable add-on. I guess I shouldn't be arguing it as somehow it's again just syntactical sugar, and I said before that I don't care too much about syntax here. I get it, for the 100-byte messages the framer just won't do anything, and for sending I have to use Connection.Send(Framer.Frame(Message)) instead of Connection.Send(Message)... these calls could basically be renamed into SendMessage vs. SendSomethingHuge. I said before that I don't care too much about these syntactical bits. I guess it's just that tying "Connection.Send(Message)" to "we assume your Message is big and terminates a TCP connection" is really counterintuitive to me.
... and I think I answered to NAME in the wrong place :( sorry github
NAME what’s convenient about the framer? In a C based implementation, very little. In a high level language implementation, however, it means I can and have it convert the high-level structured data into the on the wire format automatically, using a reusable library.
no, no, that was right. Framers can take an object by reference or value of any type, and turn them into an appropriately framed octet array. Syntactic sugar, yes, and pointless in some languages.