[Standards] Proposed XMPP Extension: IO DATA

Fabio Forno fabio.forno at gmail.com
Fri Apr 4 22:19:24 UTC 2008

On Sun, Mar 30, 2008 at 10:59 PM, Johannes Wagener
<johannes.wagener at med.uni-muenchen.de> wrote:

>  Indeed. If you read the xep you might see that the XEP is very much the
>  same as you suggest here. Ad-Hoc Commands do also support several
>  actions: For example execute/next/prev/cancel/complete are actions
>  supported by Ad-Hoc Commands. We think that this facilitates everything
>  that is required to completely manage/control a remote process. As I
>  already mentioned our approach is a very general one. The specs in the
>  XEP is that open that it is of course possible to do what you suggest,
>  for example see section 4.2 for getting the schemata. See 4.3 for
>  sending data.

Indeed for M2M I'm concerned about the lack of extensibility of the
actions of ad hoc commands, since they their only purpose is
describing the which is the next step required for performing an
operation, while they don't say anything about which kind of operation
we are doing on a node. The type of the the
http://xmpp.org/protocol/io-data child tries to fix this limitation
with some possible meanings of the command: input/output/get-schemata,
but it still uses a fixed vocabulary. Perhaps if you just allow any
value for type attribute we reach full flexibility and equivalence
with REST.

> >
>  Yes, that's why the XEP uses Ad-Hoc Commands. Because it has already a
>  session concept as you suggest here. In addition to this it is a widely
>  supported XEP, we think that - with the very generic io data container
>  in our specs - it is a friendly way to also support machine2machine
>  parseable/readable and especially marshal-able services with it. As I
>  already mentioned our approach is a very general one. The specs in the
>  XEP is that open that it is of course possible to do what you suggest
>  here: for example doing it in an asynchronous way there is the sessionid
>  of Ad-Hoc Commands - especially Examples in section 4.4 and 4.2.

I'd let the application decide which is the best way to handle the
session. For example there are session associated with a previous
authentication process and applied to different nodes, or sessions
lasting for ever, even after the restart of the service. The
session-id of ad hoc commands is limited from this point of view.
However it's not written anywhere that that's the only session-id we
can use, and this - I think - keeps the necessary extensibility for
session handling. For example the app could get an auth token logging
to a given node, and then add the token to the payload of different
commands to different nodes. I'd add an example about this to the XEP,
just for showing the the concept of session is not limited to the
ad-hoc commands scope.

Finally I think that the <in/> and <out/> children are unnecessary in
commands of type input and output, but that's just a minor adjustment.

If you agree with these two observations, I'm absolutely fine with the
XEP (I even think that it could be a better way for transporting SOAP


Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

More information about the Standards mailing list