Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
Sorry for late response... 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 believe yes. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. IoT-related items can work very efficiently over the protocol. 3. Do you plan to implement this specification in your code? If not, why not? Partially yes. A student's open-sourced code (though, not fully-working yet) is on https://github.com/akari-h/nex 4. Do you have any security concerns related to this specification? I've not noticed at the point of writings. I'd read the comments carefully... 5. Is the specification accurate and clearly written? I welcome any comments. Yusuke
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
All, Please find below my comments to Last Call XEP-0322: Efficient XML Interchange (EXI) Format (Version: 0.4, Last Updated: 2014-03-10) in section order. Hope the feedback helps, -- Daniel # 2.2.3 Uploading new schema files I propose changing the MD5 hash calculation for schema files. The idea is to build the hash by means of Canonical XML (http://www.w3.org/TR/xml-c14n). Doing so helps to identify XML/XSD documents that are logically equivalent but vary in physical representation based on syntactic changes permitted by XML. Hence, irrelevant changes do not affect hash. # 2.2.4 Uploading compressed schema files Table 1: contentType values offers beside the Text contentType two more content types for EXI, namely ExiBody and ExiDocument. In the best case the difference is one byte (the first byte differs). I would recommend using ExiDocument only and remove ExiBody. The reason is not only the minimal 1 byte overhead but also that off-the-shelf EXI processors always expect an entire EXI document with the header instead of just the body. Note: Nevertheless, I think it is perfectly fine to assume the EXI options in Table 2. Also, with the previous comment (see Canonical XML) it should be also OK to generate md5Hash with the EXI- encoded schema. Note: Section 2.2.3 and 2.2.4 could be combined given that the latter also speaks about uncompressed schema files. General Note: Does it makes sense to use mime/media-types? # 2.2.5 Downloading new schema files on server Does it make sense to add an attribute that allows identifying whether a downloadable schema files is represented in XML or EXI. e.g., downloadSchema xmlns='http://jabber.org/protocol/compress/exi' contentType=ExiDocument url='http://schemavault.example.org/compress/sn/provisioning.xsd.exi'/ Backlink again to mime-type comment (http accept/response)? # 2.3 EXI-specific stream elements a) Typo: EXP-compressed XMPP stream ... EXP vs. EXI b) Strong similarity to websocket. Why not using the same tag names? framing ideas (one stanza per frame etc)? https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ General Note: Harmonize with websocket RFC... e.g. transport binding/communication setup c) Link to XEP-0045 is not correct. # 3.1 EXI Encoding Preprocessing and Postprocessing I wonder whether in the case of prefix recovering it is enough to use the prefix/NS declarations from the initial streamStart element? If so it could/should be mentioned. https://tools.ietf.org/html/rfc6120#section-4.8.5 Typo in the post-process steps .. Prefixies # 3.2 EXI options The new option sessionWideBuffers adds a new feature. Apart from string table to me it is not totally clear what is meant by all buffers. Hence, the term buffers should be defined: * I assume all String Tables (uris, prefixes, and values) * What about evolved EXI built-in grammars, expanded global element grammars etc. # 3.3 Transmission of EXI bodies and Session-wide Buffers Question 1: Can an EXI recipient be sure that an EXI stanza is sent at once? One packet? Question 2: Can an EXI recipient be sure that a packet contains exactly one stanza? My assumption w.r.t. pure XMPP results in a No for both questions. However, harmonizing it with Websocket (see comment Section 2.3) results in a Yes and would make it easier for the decoder to identify stanza boundaries. # 3.11 Using EXI Option Documents for Shortcut Setup Duplicated last paragraph The format for these opton documents or locations is beyond the scope of this specification. Typo: opton # General NOTE What about pre-defining some default configurationId's for some typical setups e.g., - schema-less coding (does not require any schema negotiation) - XML schema datatypes only coding (does not require any schema negotiation) - maybe some very typical core XMPP schemas Doing so allows a fast setup in many use cases. Does it that make sense to exludude a given range for such pre-defined combinations also? Von: Standards [standards-boun...@xmpp.org] im Auftrag von XMPP Extensions Editor [edi...@xmpp.org] Gesendet: Mittwoch, 8. Oktober 2014 18:33 An: standards@xmpp.org Betreff: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format) This message constitutes notice of a Last Call for comments on XEP-0322 (Efficient XML Interchange (EXI) Format). Abstract: This specification describes how EXI compression can be used in XMPP networks. URL: http://xmpp.org/extensions/xep-0322.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
Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)
A short official feedback, Daniel also will be contributing more details and we have started direct discussions with the authors. Abstract: This specification describes how EXI compression can be used in XMPP networks. URL: http://xmpp.org/extensions/xep-0322.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? To my opinion yes. The most critizied point on XMPP is always that used string-based XML representation is inefficient. EXI offers an efficient binary representation of the information while still enabling a 1:1 translation between textual XML and EXI. Apart from reducing the wire load, it also is far more efficient to serializeparse (due to binary structuring and native types and instead of string representations) Thus, it offers protocol enhancements for every application where performance bandwidth is an issue - and that is not just IoT. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. 3. Do you plan to implement this specification in your code? If not, why not? We are aware of several efforts to implement the XEP and we are currently in discussions how to join them. 4. Do you have any security concerns related to this specification? None right now. 5. Is the specification accurate and clearly written? We support the comments on the mailing list. Best Regards, Johannes
Re: [Standards] LAST CALL: XEP-0332 (HTTP over XMPP transport)
On Wed, Oct 8, 2014 at 5:33 PM, XMPP Extensions Editor edi...@xmpp.org 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: iq type='set' from='httpcli...@clayster.com/browser' to='httpser...@clayster.com' id='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
Re: [Standards] LAST CALL: XEP-0332 (HTTP over XMPP transport)
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.
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 query/ 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 relates to the stuff in 4.1 If
[Standards] XEP-0354: Customizable Message Routing - Council Remarks
Thanks for accepting CMR as XEP-0354. :) I'd like to reply to the comments made by the council meeting (2014-09-24): Two members suggested to replace available / with disco. This was actually the case in one of my first drafts. But I then realized that a get/result IQ was necessary by the client, to determine the current CMR state and decided to put the available algorithms there too. The motivation was to avoid adding more disco features besides 'cmr:0' in order to increase the chance that entity capabilities between different servers still match. I know that this is a minor optimization. But I don't see a real advantage of using disco in this case, as you don't even avoid an additional round-trip (in most cases). It also feels right to split the feature (announced in disco) from the featured algorithms (announced in IQ result). But if this is a show stopper, I'm willing to put the available algorithms into the disco result. [15:07:50] Tobias i'm unsure about the use case, the use case section more describes the use cases for different routing rules...less so the use case for discovering those dynamically Addressed with https://github.com/Flowdalic/xeps/commit/3d6a3192e317c1df42419d6c403e1dab0301414b The dynamic discovery is not really an feature of CMR, it's more an side effect. What's important is that different routing algorithms can be used on the same service. [15:10:42] Tobias Kev, yeah..but what would it benefit a client knowing the server does routing X instead of routing Y? While clients that typically use CMR would always use a server that is under the same entities control that also controls the clients, it's still good to know that the service is able and does actually route the messages as the client expect them to route. Again this is just a side effect of allowing different routing algorithms on the same service and for different clients (having a different bare jid). [15:10:46] Lance it would probably be worth giving more explanation on why this is different than carbons, or how the two interact. this spec i assume is more for bots iot than humans Addressed with https://github.com/Flowdalic/xeps/commit/467674303725d7ebcc6bae8107c16c03af718b01 Carbons, if enabled, still only send the message to *all* (carbon enabled) resources. This doesn't allow for load-balancing, CMR does. Roughly speaking, Carbons is ideal for human interaction, CMR is ideal for M2M. I hope to have addressed all the issues mentioned and be happy to discuss further points regarding CMR. The current version of CMR can be found at http://geekplace.eu/xeps/xep-cmr/xep-cmr.html - Florian
