Loading ...
Sorry, an error occurred while loading the content.
 

Re: alternative transports

Expand Messages
  • dj.adams@gmx.net
    ... correct ? ... an ... 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
    Message 1 of 13 , Nov 5 8:50 AM
      > I've been working from your proposal in rpc-jig[1]. Looking through
      > the jabber docs, it appears that <iq> implies a request/response
      > exchange [even though its over an async transport], is that
      correct ?
      > if so using <message> might be better, but that would probably need
      an
      > 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 [1]. 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
      dj

      [1] http://mailman.jabber.org/pipermail/rpc-jig/2001-
      October/000045.html
    Your message has been successfully submitted and would be delivered to recipients shortly.