Re: [Standards] LAST CALL: XEP-0332 (HTTP over XMPP transport)
Am 08.10.2014 18:33, schrieb XMPP Extensions Editor: This message constitutes notice of a Last Call for comments on XEP-0332 (HTTP over XMPP transport). Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. URL: http://xmpp.org/extensions/xep-0332.html This Last Call begins today and shall end at the close of business on 2014-10-21. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? I'm not sure. Tunneling http semantics over an xmpp connection seems like a useful thing sometimes, but I think the approach described here is a very complicated way of doing this. 2. Does the specification solve the problem stated in the introduction and requirements? I had a very hard time to understand the problem and requirements. 3. Do you plan to implement this specification in your code? If not, why not? no. Reviewing just so I can make a decision in the council meeting. 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? I don't think so. Your feedback is appreciated! section 1: > The XMPP protocol however does not have the same problems as HTTP in > these regards. It's a peer-to-peer protocol naturally allowing > communication with applications and devices behind firewalls Well no. I prefer the text from https://tools.ietf.org/html/rfc6120#section-2.5 about being logically p2p here. > through established friendship relationships. We don't call being on someone else's roster and having a presence subscription "friendship" in XMPP. section 2: I fail to see where the requirement for the server to have a web server is used. section 3: RFC 2616 has been obsoleted by RFC 7230 et al in the meantime. Using some of the terminology from http://tools.ietf.org/html/rfc7230#section-2.3 might make things clearer. section 4: editorial: can the amount of bold face reduced please? style: I prefer text along the lines of the requesting entity MUST send an IQ stanza of type "get", containing an empty element qualified by the 'http://jabber.org/protocol/disco#info' namespace, to the JID of the target entity (from xep-0030) > Xml content embedded in the XML telegram XML stanza? Used several times. ed: avoiding different ways of capitalizing XML helps the reader. > Motion JPeg ed: Motion JPEG seems to be the most common capitalization. > On constrained devices with limited support for different XEP's, this > can be a way to avoid the use of technologies not supported by the > client. I still don't think that including a flag in every request is the right way to convey client capabilities. > The client can disable the use of ingle ed: s/ingle/Jingle/ section 4.1.2: > Note: The XMPP/HTTP bridge at the server Well, it's not at the server, it is located at httpser...@clayster.com "XMPP/HTTP bridge" should be explained in the glossary. I think the terminology from RFc 7230 might be helpful here. (general remark: I think using company names in those examples will limit adoption) in 4.2.7: > The first candidate should however correspond to the same stream that > would have been returned if the request had been made using normal > HTTP over TCP. I've said that before: this is not how jingle or ice works. section 4.3.1.1 RFC 2616 has been obsoleted by 7230. While 2818 is just updated, I think it's better to reference 7230. Note that the definitions seem to have changed, see http://tools.ietf.org/html/rfc7230#section-2.7.1 and 2.7.2 example 18: httpx_URL = "httpx:" "//" resourceless_jid [ abs_path [ "?" query ]] We call this a "bare jid" usually. In general, relying on the terminology of http://tools.ietf.org/html/rfc7230#section-2.3 I do not see why a new uri scheme is needed instead of considering this a "tunnel" intermediary (which I do not think the approach outlined in the XEP does). Further, it is not clear to me how the requests for this look like. Is the "xmpp/http bridge" preconfigured like a proxy? I suspect that httpx://user@host has some undesired consequences since this consitutes an authority component (because of the //) and hence the part before the @ is to be interpreted as userinfo instead of being part of the JID. In 4.3.1.2 > Friendship requests See above. > If not in the roster, the browser needs to send a friendship request Why? This whole section seems to presume XMPP-based communication between the browser and the httpx server. Whereas section 4.1 was talking about bridging. There are privacy concerns related to exchanging presence with sites "browsed" by the user. Section 4.3.1.3 strongly reminds me of the use-cases Dirk Meyer had been doing. It's not clear to me how this relate
Re: [Standards] LAST CALL: XEP-0332 (HTTP over XMPP transport)
On 8 October 2014 17:33, XMPP Extensions Editor 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.
Re: [Standards] LAST CALL: XEP-0332 (HTTP over XMPP transport)
On Wed, Oct 8, 2014 at 5:33 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0332 (HTTP > over XMPP transport). > > Abstract: This specification defines how XMPP can be used to transport HTTP > communication over peer-to-peer networks. > > URL: http://xmpp.org/extensions/xep-0332.html > > This Last Call begins today and shall end at the close of business on > 2014-10-21. > > Please consider the following questions during this Last Call and send your > feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? I do not know. > 2. Does the specification solve the problem stated in the introduction and > requirements? Possibly, subject to comments below. > 3. Do you plan to implement this specification in your code? If not, why not? Not immediately - I don't have a need for this. > 4. Do you have any security concerns related to this specification? Several, mostly around out of band unencrypted transfers, possibilities for resource exhaustion attacks, how identity verification for HTTPS is established, what happens if you try to use non-HTTPS. > 5. Is the specification accurate and clearly written? I don't think so yet. Some comments follow: Throughout should HTTP references be to 7230? The requirements say that the HTTP and XMPP servers must be collocated, but this doesn't need to be true, does it? As the glossary is entirely web terms, can this not be elided with a reference to Terminology in 2616/7230? No-one's going to be implementing 332 without also reading HTTP. "telegram" is introduced as a term of art without explanation.Use Cases needs some reworking for consistency of terms and ensuring those used are introduced or referenced. "friendship", similarly, is not generally a term of art in XMPP (applies particularly later on to 4.3.1.2 etc.). I note that requiring encoding of > isn't usually necessary in XML (we once had such a requirement for XMPP, but I'm fairly sure we got rid of it). The 'xml' encoding method needs somewhat more thought to prevent illegal XMPP being encoded (e.g. sending of data in existing namespaces, using features disallowed by XMPP). It is mentioned in passing, but doesn't provide much guidance. Considering that the amount of processing required to encode here is greater than to encode as 'text', does this encoding add value? Is EXI here that much of a motivator? The motivations for chunkedBase64 are unclear - the introductory paragraph seems to say to never use it - streams shouldn't use it, it shouldn't transfer files. It then talks about moderate sizes without a guide as to what this means. (SI) "This transfer mechanism is of course the logical choice, if the content is already stored in a file on the server" Is it? Isn't Jingle for file transfer the more obvious choice? IBB - Is having this in addition to Jingle a little redundant? IBB can naturally be included in Jingle proposals and the appropriate stream method selected. jingle=false - requiring optional parts to be disabled rather than enabled seems poorly extensible. "Note: Content encoded using chunkedBase64 encoding method can be terminated, either by the receptor going off-line, or by sending a close command to the sender." - does this mean that presence subscriptions (or presence decloaking) is required before 332 can be used, or just this mechanism? Example 1: "" Does this mean that it must be the server that supports this, rather than a client? It's unusual for server-provided services to be on JIDs with a localpart other than the user's, so some explanation here is needed. In all the examples some text is needed to explain what behaviour must be - examples are not normative, but seem to be being used as the definition of behaviour here. What versions of HTTP are supported? Does it matter? "The XMPP/HTTP bridge at the server only transmits headers literally as they are reported, as if it was normal HTTP over TCP that was used. In the HTTP over XMPP case, connections are not handled in the same way" What is the distinction here? Example 4.1.4 - what does an ellipsis for content-length mean? It seems to be illegal in the 2616 BNF. Is statusMessage properly defined anywhere? Or the mapping from HTTP onto the req/resp (why not request/response?) elements? Throughout, the urn:xmpp:http namespace should be versioned. EXI is mentioned extensively, but other compression methods also reduce the b64 overhead and similar. Doing chunking twice (one at the HTTP and once at the XMPP layer) seems quite inefficient - is this a sensible model? Can you receive HTTP chunked data over XMPP as type text? 4.2.5 - this text seems imprecise - if the content 'can be represented as a file' then you have to use sipub (although the language isn't 2119ish); can't most content be represented as a file? I'm not sure that the claim that all stream
[Standards] LAST CALL: XEP-0332 (HTTP over XMPP transport)
This message constitutes notice of a Last Call for comments on XEP-0332 (HTTP over XMPP transport). Abstract: This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. URL: http://xmpp.org/extensions/xep-0332.html This Last Call begins today and shall end at the close of business on 2014-10-21. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
