Hi, On Wed, Aug 12, 2009 at 11:33 PM, XMPP Extensions Editor<edi...@xmpp.org> wrote: >> 1. Is this specification needed to fill gaps in the XMPP protocol stack or >> to clarify an existing protocol? >> 2. Does the specification solve the problem stated in the introduction and >> requirements?
Yes to both. The specification makes a clear starting point to write implementing libraries for machine to machine communication or client libraries. On Wed, Aug 12, 2009 at 11:33 PM, XMPP Extensions Editor<edi...@xmpp.org> wrote: >> 3. Do you plan to implement this specification in your code? If not, why not? Yes. On Wed, Aug 12, 2009 at 11:33 PM, XMPP Extensions Editor<edi...@xmpp.org> wrote: >> 5. Is the specification accurate and clearly written? Yes, the specification is easy to read and understand. There seem to be only one typo in "Example 4. IO Schemata request" where type='get' is given in the IQ example even it should be type='set', right? Cheers, -- tuomas 2009/8/15 Egon Willighagen <egon.willigha...@gmail.com>: > 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<edi...@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/ >
