Re: Email binding issue

I think what we've done is reasonable and appropriate given the goals.  We 
were never trying to create a deployable protocol, which is clearly beyond 
the mandates of our charter.  We were merely trying to signal how our 
framework would apply in a non-HTTP situation, and I think we've shown 
that well.    Furthermore, coming from a company that builds one of the 
more widely deployed email systems (tens of millions of "seats"), having 
independence from any one delivery method is a feature not a failing. 
Emails tend to flow over many such systems (POP, SMTP, etc.), and to be 
gateway'd between them.  An email binding gives you a handle on submitting 
a purchase order through, for example, a corporate email transport, 
gateway'd to SMTP on the public internet, and retrieved via IMAP.   Though 
the details are different, that's essentially how I'm reading and 
responding to your emil right now.  Doing a binding specific to SMTP would 
be unnecessarily limiting.  The specific mapping that takes you from what 
we have, to actual bits on the wire using SMTP, is covered by existing 
standards.  Thanks!

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







Mark Baker <distobj@acm.org>
Sent by: xml-dist-app-request@w3.org
03/05/2002 01:40 PM

 
        To:     highland.m.mountain@intel.com (Mountain, Highland M)
        cc:     xml-dist-app@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: Email binding issue


Hi Highland,

> Mark,
> 
> In an earlier draft of this document, there were SMTP (and POP3) 
commands
> included to illustrate mail client and server interaction.  A small sub 
team
> met and decided that it is not the responsibility of SOAP to define 
email
> infrastructure communication and therefore, these commands should not be 
in
> the binding document.  The email infrastructure (i.e. which email 
clients,
> servers and associated commands along the message path) is of no 
interest to
> SOAP, just the content of the mail message.
> 
> Thoughts?

Hmm, interesting.  Is the discussion around that decision archived
anywhere?  I'm just curious about the reasoning behind it.

I think that an email protocol binding needs to bind to an email
protocol. 8-) "email" is a bit wide open, as it can refer to "email
transfer", "email access", "email synchronization" (roughly
corresponding to SMTP, POP3, and IMAP).  I assumed that this work was
for email transfer, so I expected to see a SMTP binding.  And IMO, SMTP
fits best with SOAP (since it "sends stuff"), so it would be my
preference.

Thanks for the prompt reply.

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

Received on Wednesday, 6 March 2002 10:53:40 UTC