/Puts on Council hat I'm -1 on this for now because this really needs some more discussion on the list as this duplicates quite a bit.
Technical nitpicks for proposal as is: - The 'jabber:iq:rest' name should not be used. The 'urn:xmpp:xml-rest' namespace could be used instead. - If the <resource /> element can only have the child <method />, why not use <resource method="X" />, or <method name="X" path="/foo" />? - An example showing retrieving the value of a resource would be useful. Given that XMPP nodes can represent resource paths, the proposal reduces to providing a new call/response mechanism that places the action name in an attribute value of a generic element (<iq><resource><method name="ACTION" /></resource></iq>) instead of an action-specific namespaced IQ child element (<iq><ACTION xmlns='ACTION-NS' /></iq>). Likewise, a new form description schema is provided instead of using Dataforms. I do see that there are some special types introduced, but those few special cases could be added as an extension to Dataforms instead of a full replacement. A discovery method is introduced for finding methods that a resource supports, but that is already provided by Disco#info features. Of course, Disco does not itself provide parameter definitions, but we traditionally do that by using an IQ-GET to retrieve an empty data form, followed by an IQ-SET to apply the data form. If the goal is to provide easy mappings for CRUD behaviour, then consider this straw man: Let Resource be represented by a node named "/the/resource". To find methods supported by the Resource: <iq type='get'><query xmlns='http://jabber.org/protocol/disco#info' node='/the/resource' /></iq> <iq type='result'> <query xmlns='http://jabber.org/protocol/disco#info' node='/the/resource'> ... <feature var="urn:example:xmpp:rest:get" /> <feature var="urn:example:xmpp:rest:put" /> <feature var="urn:example:xmpp:rest:post" /> <feature var="urn:example:xmpp:rest:delete" /> ... </query> </iq> Discovering parameters of the "post" method for the Resource: <iq type='get'><post xmlns='urn:example:xmpp:rest' node='/the/resource' /></iq> <iq type='result'> <post xmlns='urn:example:xmpp:rest' node='/the/resource'> <x xmlns='jabber:x:data'>...</x> </post> </iq> Performing a "post" to the Resource: <iq type='set'> <post xmlns='urn:example:xmpp:rest' node='/the/resource'> <x xmlns='jabber:x:data'>...</x> </post> </iq> <iq type='result'>...</iq> Such an approach would still need refining, but it would fit in better with existing XEPs without creating a parallel track of extensions for new method types. - Lance
smime.p7s
Description: S/MIME cryptographic signature
