[Standards] LAST CALL: XEP-0332 (HTTP over XMPP transport)
dave at cridland.net
Tue Oct 21 12:56:13 UTC 2014
On 8 October 2014 17:33, XMPP Extensions Editor <editor at 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
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:
> 3. Do you plan to implement this specification in your code? If not, why
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards