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).

* 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]:

>[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.

[..]
>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.

>   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.

[..]
>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).

>   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.

>   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.

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

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.

  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-soap-1_2-sect6.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

Received on Thursday, 19 July 2001 14:42:38 UTC