Re: TBTF: SOAP over SMTP Binding Proposal - HTML

* Mountain, Highland M <highland.m.mountain@intel.com> [2001-07-19 13:19-0700]
> >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....

I think so. These are clueful hints about the use of SMTP for our
particular case, and these are worth mentioning IMO.

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

"dispatched" would be a transport layer acknowledgement.

"processed" would be a XMLP layer acknowledgement. The interesting
part here is that it is an XMLP layer acknowledgement expressed at the
underlying protoocol layer, i.e. not necessarily in the form of a SOAP
message.

Indeed, I agree that a one way message exchange would not have any end
of process notification.

I actually wonder what the value of the end of process notification is
at the XMLP layer. Maybe an optimization in case the message was
processed and there is no output.

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

Agreed. And SMTP support several MEPs: one way, request response,
sender to multiple receivers, sender to multiple receivers with a
response, all being asynchronous.

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

I think so. What I am worried about in going into so much detail and
mixing so many technologies (SMTP + RFC822 format + DSN + MDN) is that
we are going to design a monster. :-)

This is why I had this image of a simple one way transport binding,
mentionning that it can be extended easily for:
- quality of service (MDN + DSN)
- request reply (message id, In-Reply-To header field, use of
  Reply-To, etc)

On the other hand, maybe going in so much detail is necessary to
understand fully what a binding is, so I am quite happy if people
disagree here.

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092

Received on Tuesday, 24 July 2001 10:20:31 UTC