Re: Need new MEP for SMTP binding

> Noah,
> 
> > In that case, almost all email seems to be tunneling through SMTP. 
> > Certainly the majority of my email comes with a Reply-to field as 
> > standardized by RFC 822. I'm uisng it right now to reply to your note! 

> > That feels very much like request/response to me.  I think what we're 
> > doing in sending SOAP over email is absolutely in the spirit of RFC 
822 
> > email, as customarily used through SMTP and a variety of other email 
> > systems.
> 
> Stuart and I got into an interesting discussion about this point a while
> ago off-line.  I'm not sure that we reached concensus, but I believe we
> at least acknowledged that the truth lies somewhere between "SMTP is
> already request/response" and "SMTP isn't request/response". 

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 do not think that makes SMTP request/response anymore than the
underlying IP protocol used to carry all of this is request/response.
SMTP is per hop and is one way (the email response may go over a
different path!) The RFC 2822 carried over it is often request
response.  Working as designed.



> given the potential security implications, and that it's not well known
> where this line is, I'd rather not toy with it, even as a demonstration.
> I am concerned that people would use it, or that this type of approach
> may be considered "best practice".  And I certainly wouldn't want my
> name on it - not to overstate things, but I do feel very strongly about
> this.
> 
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?  If someone wants to support submission of resumes through
email, why not support a SOAP-wrapped option to facilitate machine
handling of the requests? 

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

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


> But to get to the main point of your note;
> 
> > If what you're working on is intended to be a first class, deployable 
SMTP 
> > binding, then these details do have to be right, but I claim that's 
beyond 
> > the scope of our charter (as I say, I think they're already right, but 
you 
> > obviously remain concerned).  I would prefer not to spend time 
debating it 
> > on the critical path to last call.   Insofar as we're trying to make 
sure 
> > that it's possible to use the binding framework to build more than one 

> > binding,  I think we've clearly demonstrated that.
> 
> Are you referring to the RFC 2822 binding when you say that?

Yes.  For that matter, I think that anything that suggests a
deployable email or smtp binding is beyond the scope of our charter.
The particular binding we've offered is merely designed to illustrate
how mechanisms like binding framework properties and states can be
applied to a protocol other than HTTP.  It's to give readers a sense
of what might change and what might stay the same when you want to
invent your own binding.  I think it's just fine for that, and I don't
really see why we have to go into any of these deeper concerns.

When and if we decide to do a normative email and or smtp binding, we 
will have to clarify the requirements for it, design it carefully
to meet those requirements, and document its limitations. 

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.  Eventually, the email reaches a gateway, at which
point it is converted to SMTP, with the RFC 2822 fields in their
proper place and mailed to you.  Maybe similar conversions happen at
your end, or maybe not.

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. 

> 
> > [FWIW, the reason I think we will eventually need a new MEP is that 
the 
> > current Req/Resp is implicitly targeted at relatively rapid responses. 
 In 
> > practice, we hold the HTTP connections open and use HTTP response.  I 
> > think there will be other Req/Resp traffic that will take 
> > minutes/hours/days, and I expect that email would be more commonly 
used 
> > for that.  I would expect that systems like MQSeries could support 
either 
> > a quick or a long running req/resp.
> 
> Quick comment - I'm not sure why the current ReqResp MEP can't support
> this.
> 
> >   Anyway, having mentioned this, I 
> > want to reiterate that I would prefer to close this debate now (just 
my 
> > preference), agree that we've done everything we need to in this area 
for 
> > now, and focus on getting to last call.]
> 
> I wouldn't be against skipping this entire exercise.  It was a
> noble goal, but if time does not permit, then we should consider
> not doing it.
> 
> But I would be against saying that we've accomplished something, when
> IMO, we have not.
> 

I'm reluctant to say it, but we've both devoted long notes to this
subject, and right now it seems that we are looking at the same
facts and disagreeing about the implications.  I would like to know
whether others in the workgroup share your concerns, as I have tried
hard to understand them, and I confess that I do not.  In short,
I think it's time to wrap up this discussion, make a decision about
what to do, and move ahead.

I can only reiterate that I think the email binding we've offered is
there to meet a very limited goal that's consistent with our charter.
Doing a first class email (RFC 2822) or smtp binding is beyond our
charter, and I would rather not take the time to debate its merits on
our way to last call.  I understand that even the non-normative
binding we've offered is making you nervous, but I'm afraid I am just
not convinced of your reasons.  Thank you.

Noah

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

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 15 March 2002 18:58:21 UTC