W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

SOAP/XMPP

From: David Hull <dmh@tibco.com>
Date: Tue, 10 Jan 2006 16:01:33 -0500
To: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Message-id: <43C420AD.2090906@tibco.com>
In a previous message [1] I mentioned some potential concerns with
SOAP/XMPP, but hadn't had a chance to look through the relevant specs in
detail.  Now that I have, I'd like to amplify what I said before just a bit.

    * From the viewpoint of transport protocols (if it's not a sin to
      view a Presence Protocol as a transport protocol :-) I see two
      separate protocols: <iq/> and <message/>
    * <iq/> is basically request-response oriented.
    * <message/> is essentially one-way, even though it natively
      supports to/from addressing and message id.

I'm reasonably happy with binding SOAP request-response to <iq/>.  I'm
less happy with binding it to <message/>.  On the other hand, I would
very much like to see a SOAP one-way MEP defined and bound to <message/>.

The description of the SOAP request-response MEP states that, "In the
absence of failure in the underlying protocol, this MEP consists of
exactly two SOAP messages [or a SOAP message and an ack, if we go that
way]."  If understand the SOAP/XMPP proposal correctly, the
<message/>-based binding does not guarantee either a response or a
failure.  It seems quite possible for me to send you a <message/> and
you to simply disregard it, essentially staying in the sending+receiving
state forever.  The protocol is working fine, but I'm not.  For my
money, this is the primary distinction between "request-response" and
"two correlated one-way messages."

On the other hand, defining a one-way MEP over <message/>, which would
basically just mean getting rid of almost everything but the description
of how to put the SOAP envelope into a stanza, would allow for both
clean one-way SOAP messaging and for "asynchronous request-response". 
If you're doing plain request-response (i.e., anonymous response
endpoints), you would use <iq/>.  If you're doing anything else, you'd
use <message/>.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0022.html
Received on Tuesday, 10 January 2006 21:01:42 GMT

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