Re: [Standards] XEP-0322: EXI for constrained processing environments
Hi Rick We also believe that EXI is very useful in restricted environments. That said, w.r.t. this use case the XEP-0322 might be further improved. We shared already our ideas in the following thread [1][2]. > The fully specified path assumes starting off with fullblown XML and > then switching to EXI; this is a scenario that would work when the > viewpoint is saving bandwidth. Another usecase, where EXI serves the > relative simplicity of a client, is not really dealt with under the > usual clarity. I think you gave yourself the answer in the latter part of your mail mentioning that with a dedicated port one can start using EXI right-away. Is this approach not working for you? > As for the EXI cookie, is it an idea to use a processing instruction > and/or XML declaration that would be sent to the server? Please correct me if I am wrong but I think this has nothing to do with processing instructions. The EXI Cookie is an optional part of the EXI stream. In fact it is nothing more than a 4 byte "magic cookie" that serves to identify whether a stream is XML or EXI. Thanks, -- Daniel [1] http://mail.jabber.org/pipermail/standards/2014-October/029228.html [2] http://mail.jabber.org/pipermail/standards/2014-October/029254.html
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., 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 this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the spe
Re: [Standards] EXI in XMPP: schema negotiations
Hi Peter, all, My feedback comes rather late but I hope it is still useful. I think having the possibility to upload a compressed XML schema document is very beneficial. That said, I agree with Rumen that in almost any case you need to have Preserve.prefixes on to allow proper decoding. Also, the differentiation between the two contentType values "ExiBody" and "ExiDocument" is not really necessary. The overhead would just be one byte. Instead, I would propose having another alternative that may work well for many use-cases. The current default options point to no schemaId. A very efficient representation on the wire would be the schema for schema definitions [1]. These pre-shared grammars would largely reduce the size of the compressed XML schema stream. Hope this helps, -- Daniel [1] http://www.w3.org/2001/XMLSchema.xsd External service provider at Siemens AG 81739 Munich, Germany Von: Rumen Kyusakov [rumen.kyusa...@ltu.se] Gesendet: Freitag, 22. März 2013 11:54 An: peter.wa...@clayster.com Cc: standards@xmpp.org; public-...@w3.org Betreff: EXI in XMPP: schema negotiations Hello Peter, all, Thank you for your comments on the EXI options exchange and adding the EXI compressed schema use case in the specification! I think the text in section §2.5 captures the case and can be easily extended to incorporate new standard EXI schema formats when and if such become available. Please consider the following comments: - Predefining the EXI options to be used is very good approach as it simplifies the process and outweighs some small performance benefits that can be gained by for e.g. allowing communicating of the schema in EXI schema-mode. - I agree with the choice of the default values of the EXI options except for preserve - most schemas use qualified names in attribute values (e.g. ref and type attribute when specifying a type definition). According to the EXI specification (section §6.3): "When qualified names are used in the values of AT or CH events in an EXI Stream, the Preserve.prefixes fidelity option SHOULD be turned on to enable the preservation of the NS prefix declarations used by these values". So Preserve.prefixes should be on or a large class of schemas will not be able to be presented by the EXI compressed schema mechanism. - In my opinion the use of ExiBody and ExiDocument as a separate options of the compressed schema negotiations is unnecessary. When the EXI options are communicated in an out-of-band mechanism, which is the case of predefined options, the Options Presence Bit in the header can be set to 0 and the EXI Options omitted. Thus the difference in size of ExiBody and ExiDocument is 1 byte when EXI Cookie is excluded and 5 bytes otherwise. My suggestion is to merge the ExiBody and ExiDocument into a single option "EXI" and explicitly specifying that the options should not be included in the header as they are predefined. I am also in favor of implementing the same approach for the transmission of EXI-compressed stanzas. Instead of presenting them as a sequence of EXI bodies it is EXI standard compliant to transmit them as standard EXI documents with header and out-of-band options without including the optional EXI Cookie. This will make each stanza fully compliant EXI document with 1 byte header. - I think the information on how the client and the server use the negotiated schema information is not enough and allows for ambiguous behavior by the implementations. The issue is that it is not clear which of the negotiated schema is the main one for a particular stanza - all others should be linked through the main one with statement. This is a standard way of defining constrains and validation checks for XML and is not unique to EXI - each XML can be validated against one XML schema at a time. This XML schema can have multiple namespaces added through and be spread in multiple files but there is a single root XML schema document from which all these definitions are linked. The unique identification of the root schema for each stanza is needed to correctly build the EXI body document grammar (http://www.w3.org/TR/2011/REC-exi-20110310/#informedDocGrammars) for which a list of all global definitions are needed. It might be useful to consider using the schemaID header option + the schema md5 hash for each stanza if other mechanism is not better suited. -- Best Regards, Rumen Kyusakov PhD student EISLAB, Luleå University of Technology
