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

Re: Email binding issue

From: Jacek Kopecky <jacek@systinet.com>
Date: Tue, 5 Mar 2002 20:23:44 +0100 (CET)
To: Mark Baker <distobj@acm.org>
cc: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0203052009480.15596-100000@mail.idoox.com>
 Hi Mark,
 the following is a slight edit of what I sent earlier to 
Highland and it summarizes my points why I think the Email 
binding should _not_ be an SMTP binding.

 I am sure I'll just be stating the obvious for most of my email, 
but I need the fundaments to arrive at the desired logical 

 I perceive the following reasons for an Email binding:
 1) users called for "SMTP binding" and
 2) we want to prove our binding framework is really usable.

 The second reason has two possible interpretations:
 2a) we want to show as complicated useful binding as we can so 
that we demonstrate our framework and the MEPs as much as we can,
 2b) we want to show how the Email binding in particular is 
expressed using our MEPs and binding framework.

 I want to demonstrate that for both 2a and 2b the proposed
binding to SMTP is the wrong solution.

 First let me detour to what I think users were calling for when 
asking for an "SMTP binding".
 IMO the reason for even conceiving of moving SOAP messages in 
email is to use the widespread email infrastructure providing
 i)  nearly universal access and addressing,
 ii) off-line processing - the email is stored at the final 
mailbox (or on the intermediate email delivery path) and restored 
by the receiver when the receiver can do that.
 HTTP, as the other binding, even if not knowingly, was IMO
chosen for the same first reason and the opposite second reason.
 My interpretation of events: 
 1) People who wanted to use the email infrastructure (mailboxes,
mailqueues, SMTP, IMAP, POP3, UUCP etc.) called for "SMTP
binding" and not for "email binding" because there was already an
HTTP binding, not a "web binding". _And_ "SMTP binding" also 
sounds much more like it, "email binding" is sooo layman-ish.
 2) SMTP is the major protocol for sending email from an MUA to a 
mailbox, that's why SMTP was chosen for the name of the binding 
above, even if it's not entirely correct.
 3) The XMLP WG heard lots of voices for "SMTP binding" and went 
along (in Primer, where I succeeded to change it, and in the 
original SMTP binding proposal).

 Now points against an SMTP binding, if what we really want is to
move SOAP messages in email messages:
 1) SMTP is not always required to get an email from place A 
to mailbox B.
 2) SMTP is not always required to _send_ an email from a program 
- my program needn't use SMTP commands (HELO,MAIL from,RCPT to) 
to send an email message.
 3) Other protocol than SMTP is almost always used to _receive_ 
email (POP3, IMAP, plain file read).
 4) The binding does not extend SMTP or use any of its features 
that are unavailable in other email sending methods (AFAIK), it 
only extends the message headers, which are _not_ SMTP headers 
(the proposal used this term in places). (On the other hand, HTTP 
binding does extend HTTP by SOAPAction, 427 error code etc.)

 So how I envision an "email binding" is a simple stuff that says
"send the email message as you can" and "retrieve the email
message as you can" in the appropriate places. I don't have any
objection to adding SOAPAction header, but this does not at all
affect sending or receiving email.
 We could try to specify how to send an email using SMTP (already 
in an rfc, no changes to add), or using UUCP (probably too old 
but who knows) or by directly invoking a sendmail command (usual 
on UNIX) or by writing the email to a spool directory (also 
 We could try to specify how to receive an email from a mailbox 
using direct filesystem access (to various different formats) or 
IMAP or POP3 (common protocols).
 I doubt that we can cover everything and that we should try when 
what should suffice is, as said above, to say "just send the 
email" and "retrieve the email".

 Now if we want to show our binding framework in full, the
request-response binding in full, etc., on a binding in the
primer or somewhere, I suggest that we choose TCP or BEEP for the
underlying protocol because once we specify an overly complicated
"SMTP binding", even non-normatively in the primer, people will
start implementing and using it and will be reluctant to use
other email bindings ("That's not from w3c, man!") and it will be
a major PITA.

 Hope I'm clear enough,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
Received on Tuesday, 5 March 2002 14:23:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:47 UTC