SOAP/XMPP

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