On 8 October 2014 17:33, 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? > It's not clear to me that even if it *is* filling a gap, it's filling it in the right way. I can understand the notion of being able to handle specific protocols such as SOAP over XMPP, but I'm not clear why SOAP/HTTP/XMPP is better (for any values of better) than SOAP/XMPP (as described in XEP-0072). I suspect that if it's desirable to tunnel DLNA/UPnP over XMPP, it'd be best to provide a more natively-encoded form. > 2. Does the specification solve the problem stated in the introduction and > requirements? > I'm not entirely sure that this represents a truly equivalent transport as compared to traditional HTTP. I think it's rather a concern that it's modelled very strictly against HTTP/1.1 rather than HTTP/2.0 as well, but that would in many respects make things worse. Really, this specification could be said to aim to solve the problems, but it overshoots thoroughly, by being excessively generic. We may as well defined a Jingle mechanism to tunnel TCP, so we can have IMAP/Jingle/XMPP and claim XMPP handles mail, as well as running HTTP over it just as well. Overall, I think the design feels rather like this: https://www.youtube.com/watch?v=GXkTHI79T-U > 3. Do you plan to implement this specification in your code? If not, why > not? > No, because I fail to see a use-case for it that cannot be solved by better means (for example, using XEP-0072 for SOAP based services). > 4. Do you have any security concerns related to this specification? > I agree with Kevin Smith's comments here, and also add automated subscriptions to this list. I note that Kev mentions HTTPS here; I'm surprised, because HTTPS is mentioned only passingly throughout the XEP. I don't think the document considers transport security at all. > 5. Is the specification accurate and clearly written? > Several things concerns me, but most are covered in Kev's comments. I would particularly echo the decision of the author to reinvent almost every term of art in both XMPP and HTTP. Remaining that I've not seen raised: a) The URI syntax seems bent, if not outright broken, since the user-info portion of the URI actually maps to a part of the host in semantic terms. I think the URI's host part should consist of a jid, encoded as required. Even if this use of bare-jids and user-info is enforced, I note that the domain portion of a jid is an internationalized domain in UTF-8, and a URI is bound to 7-bit ASCII. b) The URI registration form suggests Peter Waher as change controller, whereas the change controller should be the XSF. c) The registration form claims to be a template. Pretty sure it's not. It's also in the wrong format. d) The restriction on HTTP service jids to be of the bare jid form (or, as this document calls them, "resourceless jids") seems to be an arbitrary restriction forced upon it by the URL syntax, but it precludes using an ordinary XMPP client session to provide the service. e) REST does not mean that. Overall, I do not think this document is of sufficient quality for Draft status, and even if it were a Draft quality XEP, I do not think this is an architecture worth pursuing. Dave.
