[Standards] LAST CALL: XEP-0244 (IO Data)

Egon Willighagen egon.willighagen at gmail.com
Sat Aug 15 07:14:34 UTC 2009


Hi all,

not sure I am supposed to reply to this as author of the XEP, but here
goes... I hope it will trigger more replies to the call.

On Wed, Aug 12, 2009 at 11:33 PM, XMPP Extensions Editor<editor at xmpp.org> wrote:
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?

To me it is. It defines clearly the content of an <iq> with respect to
the data type and allowed content. The specification describes how
clients can query the allowed content with the service in a simple and
well defined manner. I like this simplicity, making it easier to write
100% implementing libraries.

> 2. Does the specification solve the problem stated in the introduction and requirements?

The XEP introduces an alternative data container with strong data
typing (going beyond xs:string), which we are happily using in
machine-to-machine settings, in our XMPP web services environment.
Using XML Schema the data type is well defined, such that clients can
even on the fly build Java models of that schema and use that to
create a IO-Data message.

> 3. Do you plan to implement this specification in your code? If not, why not?

We are using Johannes Wagener's

  http://xws4j.sourceforge.net/

And I know if this client implementation by Tuomas:

  http://www.lobstermonster.org/examples/ws1.bmc.uu.se/

> 4. Do you have any security concerns related to this specification?

Data input is generally a source of failures of services, and IO-Data
does not change that. However, the strong data typing makes it much
easier to validate the input, though it depends on how strong the
schema implements data types.

This XEP does not introduce new security issues.

> 5. Is the specification accurate and clearly written?

I understand it :) So, I leave this to others to comment on.

Egon

-- 
Post-doc @ Uppsala University
http://chem-bla-ics.blogspot.com/



More information about the Standards mailing list