Some short answers: > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes. > 2. Does the specification solve the problem stated in the introduction and requirements? Yes. > 3. Do you plan to implement this specification in your code? If not, why not? Yes. > 4. Do you have any security concerns related to this specification? No. > 5. Is the specification accurate and clearly written? Yes. Now with the short answers out of the way, I do have some concerns. The specification does three things: One, it defines a way to do ad-hoc commands asynchronously (possibly across user sessions). Two, it defines a new payload format for ad-hoc commands. Three, it defines a schema discovery format. I think at least the asynchronous ad-hoc command part deserves to be separate from the other two. What I would prefer: 1. An Asynchronous Ad-Hoc Commands XEP. 2. The IO Data custom payload/schema format in an IO Data XEP, but as payload for ad-hoc commands, not just asynchronous ad-hoc commands. 3. Other formats in the future (SOAP, whatever). I would love a WSDL discovery XEP. Some problems with the XEP: 1. The XEP basically allows a service to expose a set of global functions. There is no possibility for function namespaces. This is similar to the SOAP over XMPP XEP, where you can have only one service end point per-JID (which I consider a non-minor deficiency). 2. The schemata discovery protocol requires at least two IQ requests per exposed function. For a service exposing a large number of functions, this makes it impractical to use for generating marshalling code at runtime. And there’s no allowance for caching the schemas (i.e., you have to load all of them every time, since there is no assurance that it didn’t change since you last checked). For something like Prosody, where we might be exposing hundreds of functions, which can appear and disappear when modules (including third-party modules) are loaded/unloaded, this makes for some nastiness. -- Waqas Hussain
