W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: Need new MEP for SMTP binding

From: Mark Baker <distobj@acm.org>
Date: Thu, 14 Mar 2002 21:48:31 -0500 (EST)
Message-Id: <200203150248.VAA12334@markbaker.ca>
To: noah_mendelsohn@us.ibm.com
Cc: xml-dist-app@w3.org
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".  And IMO,
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.

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?

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

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Thursday, 14 March 2002 21:44:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT