Re: alternative transports
> I've been working from your proposal in rpc-jig. Looking throughcorrect ?
> the jabber docs, it appears that <iq> implies a request/response
> exchange [even though its over an async transport], is that
> if so using <message> might be better, but that would probably needan
> additional value for the type attribute defining.Hi Simon
You're right, and indeed later in the thread you pointed to on the
RPC-JIG mailing list, I (and others) seemed to agree that the
<message/> element could be used as well . That is to say, the IQ
model is appropriate for request/response usages of SOAP, and the
message model is appropriate for the async, one-way and multi-hop
usages. There's no reason why we need to restrict ourselves to just
one Jabber element. I think I drew a parallel somewhere in that
thread to the split-personality of many of the standard jabber:
namespaces, e.g. jabber:x:oob and jabber:iq:oob.
May I humbly suggest we continue this on the RPC-JIG list, so as not
to lose focus or messages?
Thanks, and thanks for your input