Protocols

I wanted to respond to the bulk of Noah's comments, because I would
guess that his views are shared by many/most WG members.  But I didn't
want to do it in a way that would hold up WG progress, so please
consider this discussion a sidebar.

> Well, my view is: SMTP itself is not request response, in the sense
> that you mean, BUT it's primary raison d'etre is to support (what is
> often) a request/response email protocol (RFC 2822).  SMTP is merely a
> per-hop building block.  The level we're interested in is the
> end-to-end delivery of email.  To suggest that RFC 2822 Reply-to over
> SMTP is not a common and intended use of SMTP strikes me as strange.

I'm not suggesting that, only - as I described in my previous message -
that it's not a protocol.

> The use cases that I imagine for SOAP over email include the sorts
> of things for which email is already used.  As a simple example,
> imagine all the subscribe/unsubscribe messages that are commonly
> sent to list managers.  Why not structure these messages as SOAP
> messages?

This is a good example. Subscribe/unsubscribe is a protocol that is
tunneled over SMTP.  I won't argue that it isn't commonly used though.
I would even argue that it is a *good* thing if a sub/unsub protocol
were standardized, with or without SOAP, and even if it was tunneled
over SMTP.  I say this because currently, there are many protocols
(one per implementation, rougly) that perform these tasks, and nobody,
AFAIK, has analyzed them for security.  For example, can it be proven
that there is no way to subscribe or unsubscribe somebody who didn't
request it?  Or is there a race condition that might subscribe me
more than once?

> If someone wants to support submission of resumes through
> email, why not support a SOAP-wrapped option to facilitate machine
> handling of the requests? 

That would be fine too, but I'd prefer it if "submission" means nothing
more than the SMTP DATA method.  If submitting a resume dispatched a
request for confirmation back to the submitter, then this has now become
a new protocol, and SMTP DATA semantics are no longer in use (or, more
precisely in this case, they've been extended).

Some protocol extensions obviously have more security issues than
others.  The worst case scenario if somebody found a security hole in
the resume submission protocol, may be that a third party could
prevent the submission of a resume.  For other protocols built on SMTP,
the implications could be worse.

*This* is the reason why I have no interest in building a generic
end-to-end request/response protocol over SMTP.  Request/response can
be used as a base for accomplishing anything, as we've seen SOAP used
for.  It's a slippery slope.

It's my understanding that this is what some people in and outside the
WG are expecting from a SOAP/email binding.

> I'm sorry.  I really just don't see the concern.  No doubt there are
> many applications for which SOAP/email and in particular
> soap/email/smtp is an inappropriate combination.  So, we won't use
> it for those.

That's fine, but building request/response isn't a "use" per se.  It's
a base for many uses.

> I see it as an excellent substitute for much of
> what today is done with fax machines.  How much security do you
> have there?  It's still used all the time, and higher level
> business processes are needed to ensure that everything is OK.
> Why is sending a resume wrapped in SOAP message via email any
> worse than sending it in some other form of email? 

It isn't, unless some additional interaction requirements were added
that made it a new protocol, as I described.

> Even if the concerns you raise do prove to be significant, I don't
> see why we need to resolve them to meet the goals we've set.
> We are NOT promoting use of the binding.  Merely illustrating
> use of the binding framework (named properties, etc.)

IMHO, any form of publication is promotion to some extent.

> Even then, I believe that an RFC 2822 binding will be far more useful
> than an SMTP binding.  When I send you this email, it will not be
> through SMTP.  It will leave my machine using a set of protocols
> implemented within our Lotus email products.  These protocols are
> designed to meet the needs of Lotus corporate email customers, of
> which we have tens of millions.  The fields of RFC 2822 are
> essentially set (though encoded somewhat differently), but SMTP is not
> in the picture.

It may not be SMTP, but you need a protocol there to assign "email
delivery" semantics.  Without it you're left with what looks like RFC
2822 over TCP, which could be interpreted to mean many things;

- store this document on a bulletin board for the user
- fax this message to the boss of the identified person
- sky-write it above the house of the person
etc..

> If I express SOAP in terms of RFC 2822, then I immediately understand
> how to send you a resume or an unsubscribe request through the
> path I've just described, or indeed from most any other combination
> of email systems that are likely to be out there.  An SMTP binding
> follows more or less directly from the RFC 2822 binding, I think,
> but it only describes one hop in the process. 

It's a bit more than that; SMTP is what gives it the "sending email"
semantic.  Nothing in RFC 2822 does that.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Sunday, 17 March 2002 16:54:43 UTC