RE: TBTF: SOAP over SMTP Binding Proposal - HTML

Attached is the Figure 1 image file referred to in the SOAP/SMTP Binding.
The image illustrates the first alternative in section 1.1.3.1 "SOAP Node
Processing Distinct from SMTP Delivery Status", with the option of tying the
SMTP Receipt Confirmation to the SOAP application logic.  That does not mean
I am advocating that alternative, but just selected it to illustrate the
architecture.  If another diagram for the second alternative would help the
conversation, I can create it. 

Hugo - Thanks for your feedback.  I have answered your comments below,
prefaced by HMM.

-----Original Message-----
From: Hugo Haas [mailto:hugo@w3.org]
Sent: Thursday, July 19, 2001 11:43 AM
To: XML Distributed Applications List (E-mail)
Subject: Re: TBTF: SOAP over SMTP Binding Proposal - HTML


Thanks Highland Mary.

Here are a few comments (note that figure 1 is still missing, so I
did without it).

HMM - See Attachment.

* Mountain, Highland M <highland.m.mountain@intel.com> [2001-07-19
09:03-0700]
[..]
>1         SMTP Binding Proposal
>
>1.1.1            Related Documents
>
>   
>   The Simple Mail Transport Protocol (SMTP) is specified through a
>   series of RFC documents.  Readers of this Transport Binding proposal
>   should refer primarily to the following documents:
[..]

RFC821[18] is the specification of the protocol itself. SMTP transfers
mail data, which is described in RFC822[12]:

HMM - We can add this.

>[12]RFC822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
[..]
>1.1.2            SOAP SMTP Requests
>
>   (Sending an Email Message)
>   
>1.1.2.1         Addressing and Dates
>
>   All email header addresses MUST be RFC 822 compliant email addresses.
>   
>   The date header field MUST be RFC 822 compliant date.

I think that this is the discussion we just had on the telcon: how
much of other specifications should there be in the definition of a
binding.

Saying that the serialization uses RFC822 should be enough IMHO.

HMM - Agreed, what about the possibility of broadcasts to multiple
addresses, cc's, reply-to's.  Shall we advise on the usage of these....

[..]
>1.1.3.1         Alternatives
>
>   
>   SOAP Node Processing Distinct from SMTP Delivery Status
>   
>   Email Delivery Status is separate from SOAP layer message processing.
>   Resulting SOAP responses to the contained SOAP data will be processed
>   through a new email message with no link to the original requesting
>   email at the SMTP level.
>   
>   
>   SOAP Node Processing Bound to SMTP Delivery Status 
>   
>   Email Delivery Status is tied and bound to SOAP message-processing
>   request and the MUA's processing of MDN's is held until the SOAP node
>   completes processing of the SOAP envelope received.  The resulting MDN
>   will carry information of the success or failure of the SOAP request.
>   
>   
>   Questions for discussion:
>   
>   Shall the MUA be tied to the SOAP node regarding MDN processing?

There is a similarity here with the 200 OK status code of HTTP. When
and on what evidence can the underlying protocol say "ok"?

I think that it really depends on what the MUA wants to report.
"dispatched" is "ok, I have forwarded that to the SOAP layer". The
"processed" status needs a tighter interaction indeed, with the SOAP
layer reporting back to the binding that it's done.

I was having a look at the abstract model[19] and I am still
struggling to see how, in the case of a one-way message, the binding
can be notified of the end of the processing. I will have to get back
to that.

HMM - A one way message exchange would imply no end of process notification
response, correct? 

>   Shall we use MDN's to notify sender of successful processing of SOAP
>   data, or shall we have a distinct break between email delivery success
>   and failure and SOAP message processing success and failure?
[..]

In my (layered) view, these are two separate things:

"dispatched" means that the SOAP layer has been handed the message.
"processed" that the SOAP layer did something about it.

Do you intend to make this reporting mandatory? I originally had in mind
a very simple SMTP binding which was:
- stick the message in an RFC822-compliant format.
- identify the endpoint with mailto: URI.
- send a one-way message.

HMM - A one-way message exchange seems very simple.  A decision should be
made across all bindings regarding Message Exchange Patterns supported.


[..]
>2.1.1            Notes to SOAP Application Developers
>
>   
>   Application developers can use the Internet email infrastructure to
>   move data as either email text or attachments.  It is the application
>   developer's responsibility to parse through the email contents and
>   pass it to the appropriate software module for processing, potentially
>   creating a proprietary data exchange format.  If the data cargo is
>   passed as an attachment, verifications have to be made to ensure that
>   the attachment is of the correct type.  There is also the complication
>   of partial email messages.  These occur when an email message is
>   larger than an email infrastructure allows.  The original message is
>   split up and numbered for reassembly.  There is no guarantee that the
>   partial email messages will be delivered in the proper order.  This
>   creates the need to place the partial messages back in the correct
>   order and then piece them all together once they arrive.  Delays in
>   email delivery will further complicate development, creating the need
>   for predefined timeout periods.

Am I wrong when I read that as: "The SOAP stuff could be anywhere in
the message"?

As Chris did in his HTTP binding[20], the message body should be the
SOAP message, specified through the Content-Type as defined by
RFC2045:

        Content-Type: application/soap+xml
	        (or whatever is chosen)

It could also be specified that other encapsulation mechanisms could
be used (e.g. a mime/multipart package).

HMM - The binding spec should clearly specify the appropriate way(s) to
encapsulate the SOAP message, agreed.  This was an informational paragraph
to call out the challenges faced when transporting application data using
email.  We may still have a problem with split messages due to email
infrastructure constraints. 


>   While SMTP is not a guaranteed delivery protocol, Delivery
>   Notification mechanisms exist, but also are not guaranteed.  Email
>   users have grown accustom to requesting Delivery Receipts and Read
>   Receipts for the email messages they send.  The underlying protocol
>   mechanisms are called Delivery Status Notifications (DSN's) and
>   Message Disposition Notifications (MDN's).  These notifications take
>   the form of email messages sent to the email address specified in the
>   mail header.  Applications, as well as email end users, can use these
>   mechanisms to provide a status of an email transmission.  The
>   application developer must fully understand the capabilities and
>   limitations of these Delivery Notifications or risk assuming a data
>   delivery when none occurred.
>   
>   Delivery Status Notifications (DSN's) acknowledge the delivery of an
>   email message to a destination mailbox on a mail server or MTA.  DSN's
>   are provided through Extended SMTP servers, which have been partially
>   deployed throughout the industry at the date of this writing.  Due to
>   the partial deployment of ESMTP, a DSN request may be inconclusive if
>   a non-ESMTP server is found along the email delivery path.  DSN's only
>   notify the sender that the email message has been delivered to the
>   appropriate mailbox, not that the intended recipient (or application)
>   has opened the message and processed it.  ESMTP servers are mandated
>   by the protocol to honor DSN requests.

I think that this discussion of DSN should be left out, telling people
that they can augment the SMTP binding for (more) reliable delivery by
using extensions such as DSN.


HMM - agreed, just informational to get us thinking about SMTP and its
limits

>   Message Disposition Notifications (MDN's) acknowledge to the sender
>   that the intended recipient has received and opened a particular email
>   message.  SMTP, being first and foremost an email protocol, protects
>   an end user's right to privacy by allowing a mailbox user, at the MUA,
>   to ignore requests for read/processed return receipts.   Put in common
>   language, a user not wanting others to know when he has opened an
>   email message, can elect to ignore such request.  Application
>   developers need to understand this potential disregard of MDN requests
>   while developing SMTP data transmissions.  Decisions will have to be
>   made to handle a no MDN response situation, because it could mean that
>   MDN replies have been disabled, or it could mean that the email system
>   did not complete the delivery to the end destination.

Again, I think that MDN should be an unspecified extension.

HMM - Are you implying that we would expect developers to use MDN's as they
see fit, without going into detail in our binding spec?


One think that should be mentioned is that RFC822 does provide message
correlation out of the box.

HMM - agreed

Section 4.6.1 defines the Message-Id header field, and section 4.6.2
defines its counterpart, the In-Reply-To header field. It also
provides some sort of "conversational correlation" (i.e. references to
several related messages) with the References header field.

HMM - agreed

  12. http://www.ietf.org/rfc/rfc0822.txt?number=822
  13. http://www.ietf.org/rfc/rfc2045.txt?number=2045
  14. http://www.ietf.org/rfc/rfc2046.txt?number=2046
  15. http://www.ietf.org/rfc/rfc1894.txt?number=1894
  16. http://www.ietf.org/rfc/rfc2852.txt?number=2852
  17. http://www.ietf.org/rfc/rfc2298.txt?number=2298
  18. http://www.ietf.org/rfc/rfc0821.txt
  19. http://www.w3.org/TR/xmlp-am/#Sec5.1.3
  20.
http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/att-0161/01-xmlp-so
ap-1_2-sect6.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092