> How is this materially different to XEP-0050? I do see a difference in that the description of the resource/node should be done in a well-known way, which is my main concern with XEP-0050 (ad-hoc command, AHC), as the Data forms of XEP-004 are simple to use yet restrictive. Also, a main difference would be that one node is equal to one command, while you can have several interactions with a resource (classical REST pattern being CRUD through HTTP POST,GET,PUT,DELETE), so it could be mapped onto a two-step AHC, one selecting the interaction and the second providing the Parameters. Please correct me if one of the above statements is wrong, I am still in exploration of the patterns around disco and AHC.
> You can already do REST over XMPP using XEP-0332 (HTTP over XMPP) I also agree that while XEP-0332 provides a good way to tunnel existing HTTP-based REST endpoints (including UPNP+) through XMPP, I do see a white gap for a pattern for Resource-oriented protocols/applications over XMPP. My comments on the proto-XEP: The power in a RESTful or generally a resource-oriented architecture is that a small set of services is applied to flexible and range of resources. I do understand and support the idea to extract the primitives/basic interactions of the RESTful pattern and deploy them independently of HTTP. However, there should be a clear set of Methods that is available which would be the primitives corresponding to the HTTP verbs plus probably some more (discovery, subscription/observe etc.). if using a new format based on WADL, I think it would be beneficial to define rules how to convert from WADL (which might be still evolving). Still, I think converting WADL from HTTP-bound to XMPP-bound is one way to start, but might be a lock-in. An addition/alternative would be family of internet drafts around IETF CoRE. There, certain patterns are defined as “interface” for a resource (a resource can have more interfaces). They are picked up by several other standards and industry consortia (e.g. OIC), however, what is missing there is the above-mentioned abstraction from the concrete mapping (which is CoAP) in that family so that it can be applied to other protocols. In the W3C WoT IG Task force, we have ongoing discussions to provide a resource-oriented application layer in a protocol-agnostic way that is then mapped into several protocols (the first one being HTTP, CoAP and XMPP) as the IETF and W3C as well as several core industrial partners are involved it has the potential to gain relevance. See a living document here: https://github.com/w3c/wot/blob/master/TF-AP/Example_sketch.md (inputs greatly welcome, but might need IPR statements/clarification – dplease note ocument is Creative Commons Attribution 3.0 License) It is of course ongoing work, so it could be taking time until an actual input to the XEP is generated in form of the above-mentioned mapping, though it might also make sense to have this proto-xep in line or enabling the approach. However, a valid point is here that it is targeting especially the IoT space, though the definition of “Thing” is here a general virtual representation of real-world and abstract entities. -- Johannes
