TBTF: SMTP Request/Response Sample Binding Schematic Description

> SMTP Sample Binding
> <Henrik's Sample Binding Spec>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.</Henrik's Sample Binding Spec>
> 
> Diagram explanation
> 
> Sending - Outgoing Message Processing
> 
> At the sender, the mandatory properties need to be transformed into the
> SMTP wire representation.  This "on the wire" representation would include
> the email message body, attachments and SMTP header information.  In the
> attached diagram, incoming data and implied processing are shown at each
> SOAP/SMTP component.  The sending SOAP node needs to have some notion of
> the application envelope template.  The content of the SOAP.Envelope is
> constructed and passed to the "module" which adds the Transport Binding
> SOAP header extensions to the SOAP Content. (see Issue #1 below) Any
> necessary SMTP based header content is then wrapped around the SOAP
> Content for "on the wire" transport (open issues - where is security,
> encryption handled).   
> 
> Receiving - Incoming Messages 
> 
> The receiving SOAP node will receive the SOAP envelope data, which may
> include SOAP Binding extension information as well as application specific
> envelope template data.  The receiving node must reconstruct this data as
> specified in the Binding and SOAP Envelope Template.   
> 
> Responding  to the Original Sender
> 
> Note about Correlation
> <Henrik's Sample Binding Spec>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 2822
> <http://rfc.net/rfc2822.html>.
> 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.</Henrik's Sample Binding Spec>
> Responding to an original request using the In-Reply-To header will
> inherently provide a tie back to the original request at the sender.  A
> response SOAP.Envelope template will provide a format for the response to
> a given transaction.  The SMTP content will then be assembled, as
> specified under Sending - Outgoing Messages, prior to transport.
> 
> 
>  <<SMTP Binding Picture 815.jpg>> 
> 
> SMTP Issue 1 - We discussed having a separate ?.destination property for
> the receiving SOAP Node and another property for the binding
> specification. Did we decide to have 2 separate properties?  I would vote
> for 2. 
> SMTP Issue 2 - Where is security / encryption handled?
> 
> 
> 
> Highland Mary Mountain
> 
> Intel Corporation
> eBusiness Solutions Lab
> (480) 552 - 3817
> 
> highland.m.mountain@intel.com
> 
>