[Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

Peintner, Daniel (ext) daniel.peintner.ext at siemens.com
Tue Oct 21 08:29:10 UTC 2014


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


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.
<downloadSchema xmlns='http://jabber.org/protocol/compress/exi' contentType="ExiDocument"


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

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.

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


# 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


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-bounces at xmpp.org]" im Auftrag von "XMPP Extensions Editor [editor at xmpp.org]
Gesendet: Mittwoch, 8. Oktober 2014 18:33
An: standards at 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 at 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!

More information about the Standards mailing list