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


From: Peter Saint-Andre <stpeter@jabber.org>
Date: Wed, 18 Jan 2006 13:51:42 -0700
Message-ID: <43CEAA5E.8070709@jabber.org>
To: David Hull <dmh@tibco.com>
Cc: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
David Hull wrote:
> 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.  

That is accurate. The XMPP <message/> stanza is really fire-and-forget 
(or to use your more accurate phrase, "two correlated one-way messages") 
because it does not have guaranteed request-response semantics (as <iq/> 

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

I'll be happy to update JEP-0072 ("SOAP Over XMPP") to reflect whatever 
MEP consensus we reach here.


Peter Saint-Andre
Jabber Software Foundation

Received on Wednesday, 18 January 2006 20:51:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:28 UTC