Re: Email binding, notes

Yves Lafon wrote:
> On Tue, 29 Aug 2006, David Hull wrote:
>
>> Attached please find a sketch of a binding of the one-way MEP to email,
>> taking the existing email binding note as a starting point.  As one
>> would hope, the meat of it is in the mapping between properties and
>> email content (Table 2) and in the mapping of error conditions to SOAP
>> faults (which I've completely punted -- but then am I required to do
>> anything?).
>
> I'm not sure that the one way MEP is adapted for an email binding,
> especially if you have all the machinery to do protocol-level
> correlation. While there is not a big issue to have multiple receivers
> for a true one way message (as there is no way to do correlation, so
> you know that there is NO chance that you will get faults or replies),
> but for something like email where you may have, via the message id a
> way to correlate request and responses, it seems quite problematic to
> say that it is one-way.
>
If I understand this, you're referring to the presence of things like
reply-to: and message-id: in email.

I don't see this as a problem.  If I send you a piece of SPAM and you
don't reply, I've sent you a message one-way.  If I send you a
fascinating essay and you reply to me with insightful comments, I've
sent you a message one-way and you've sent me a message one-way.  If I
send an annoying message to the group and everyone uses the reply-to: to
flame me (not that this would ever happen :-), I've sent the group a
message one-way and the members of the group have sent me messages one-way.

The whole point of one-way, as the WSA spec once said, is that anything
else at all can be built from it.  The whole point of the one-way MEP
spec is that people can write bindings that tell how to do this basic
step with a SOAP envelope.  Restricting this to situations where one
could not be expected to continue the conversation seems limiting.

How else would you handle email?  Email is definitely not a
request-response protocol.  If there's a MEP native to email, it would
have to be some sort of "thread" MEP.  You'd have to define it
recursively as a tree with an original message at the root, then
replies, then replies to replies, etc.  You might also want to define a
"forwarding" MEP, since "this message forwards that message" is an
important relationship in the email world.  And who knows what else?

I don't see anything wrong with defining some sort of application-level
"thread" or "forwarding" MEP, if that's of use to someone, but you
shouldn't have to define all that just to send SOAP over email at all
outside a strict request response.  Defining a one-way MEP and binding
it to email handles the details of putting SOAP envelopes into MIME,
etc., providing a building block for higher-level constructs to re-use.

Received on Tuesday, 5 September 2006 06:11:50 UTC