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 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!
