Here are a few sample bindings that cover the initial set of properties. Take it with a grain of salt! Note that I here don't describe the "envelope" property but this should be quite straight forward
HTTP is a stateless client/server protocol where the client initiates a request to the server after which the server responds with a response message over the same underlying bidirectional communication channel in a synchronous manner. Intermediaries can be inserted into the path extending the request/response model over multiple, cascaded underlying communication channels. If there are intermediaries in the path, the client also needs to know the hostname and port of the first proxy server - all other intermediaries are hidden from the client although their presence can be detected by inspecting the response.
The HTTP message flow can be illustrated in Figure 1 where the numbers indicate the order in which a message flows:
Figure 1: HTTP message flow
Off-line scenarios are supported via caching of responses to the safe and idempotent request method names GET and HEAD. In this case the response may have been cached by a cache in which case end-to-end communication may not be required. For unsafe, non-idempotent requests like HTTP POST, HTTP requires a live end-to-end communication.
The server does not need to know the name of the client or the intermediary because the correlation is implicitly maintained by the underlying communication channel for each hop—an open TCP connection—so it implicitly knows where to send the response: the same way back as where the request came from in a synchronous manner.
Because a client is inherently nameless—it doesn't have a URI— a HTTP request/response interaction can be aborted by resetting the underlying communication channel.
At a naming level, in order for the client to send a request, the client needs to know the URI of the resource that is the ultimate destination of the request. The response is always a resource manifestation of the resource - never the resource itself.
SMTP is a stateful, relay based client/server protocol designed for exchange of one-way messages. A sender-SMTP establishes a two-way transmission channel to a receiver-SMTP. The receiver-SMTP may be either the ultimate destination or an intermediate. SMTP commands are generated by the sender-SMTP and sent to the receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the sender-SMTP in response to the commands. SMTP is explicitly designed for off-line scenarios based on a store-and-forward model with some implicitly defined reliability quality of service defined by each implementation.
In Figure 2 an example of a mail message exchange is illustrated in Figure 2.
Figure 2: SMTP message flow
In theory, a user can use any SMTP relay to send mail messages to any receiver but for administrative reasons, access to SMTP relays is protected in order to avoid abuse. MTAs are explicitly not allowed to look into the payload of the message but does routing only. Discovery of MTAs is typically done using MX DNS records.
Because SMTP is fundamentally about the exchange of one-way messages, message correlation is a higher layer concept with no constraints from SMTP itself. For example, SMTP does not require that related messages are returned to the same party that sent the initial message nor imposes any time constraint on the delivery of related messages. This is true even in the case of the presence of a "Reply-To" header field in a message.
Correlation is done based on a message id and either a "In-Reply-To" of "References" header field as defined by RFC 822.
Because message correlation is separate from the message exchange, there is no way to recall or abort a message once it has entered the system.
SMTP provides a naming model where both the user sending a mail message and the user(s) receiving a mail message are named—they both have email addresses (not taking into account the special case of spam mail etc.)— both of which can be groups of users or individual users. Users interact with "Mail User Agents" (MTAs) which drop off mail and pick up mail from "Mail Transfer Agents" (MTAs). Messages can have multiple recipients and can be sent to groups that are expanded at a MTA.
SMTP provides support for both "blinding" of names (hiding of internal names from the outside world) as well as "progressive discovery" of names (forwarding)
TCP provides a bidirectional reliable, ordered byte stream that because TCP doesn't have any concept of a message can be used for any point-to-point message exchange pattern. In other words, all message semantics are defined by the upper layer protocol rather than by TCP .
Because TCP doesn't provide any message semantics, it does not provide any message correlation mechanism
TCP defines a host-level naming model based on a combination of an ip-address and port of the initiator and the receiver of the TCP connection allowing for multiplexing communications. A set of well-known port numbers provide known services such as telnet, FTP, HTTP, SMTP, etc. each of which often provide their own naming model targeted the granularity provided by that service.
While applications in general do not have access to a priori determining all parts of the name of a TCP connection, various mechanisms like the FTP negotiation of a data channel or the ONC-RPC portmapper mechanism have been used for dynamically negotiating a non-well-known port for use by a specific service. Other services like HTTP uses only a well-known port and because the communication is strictly client/server the name of the other end of the TCP connection doesn't matter.