[Standards] Proposed XMPP Extension: Stream Compression with Efficient XML Interchange

Dave Cridland dave at cridland.net
Mon Feb 18 13:17:27 UTC 2008

On Sat Feb 16 10:18:37 2008, Fabio Forno wrote:
> Did some homework about EXI.

As did I - not that I'm claiming expertise quite yet. Some random  
notes follow.

I basically agree that we don't want to be doing this as XEP-0138,  
for a number of reasons, including it being an additional round-trip,  
but it works as a way of doing some experimentation.

What's currently concerning me is that a single schemaID option may  
be present, which indicates the single schema you've used for  

Currently, we have no such single schema, and in the absence of such  
a schema, my understanding is that the bulk of the performance of EXI  
is down to its usage of DEFLATE - thus somewhat contradicting those  
people who've been telling me that DEFLATE is a Bad Thing for mobile  
devices, but EXI is fantastic. Ho hum.

The schemaID is non-restrictive - that is, that use of a schemaID  
wouldn't restrict usage of other schemas. So specifying bling use of  
EXI is insufficient for our purposes - we need to define a single  
schema which represents the overall schema used for the stream.

On top of that, the more accurate that schema is, the better  
compression will be achieved - out performing DEFLATE by a reasonable  
margin. This suggests that the more we put into our master schema,  
the better - so we probably want more than one of them, to allow for  
different deployment types to handle their cases optimally.

So it seems to me that if we were using EXI in XEP-0138, a single  
"exi" algorithm isn't sufficient to grant interoperability. Instead,  
we need a method for negotiating schemaIDs, codecs, and the various  
other random options. In particular, we probably want the  
precompression option available, for the rather odd case of doing  
DEFLATE in TLS, but EXI in XEP-0138.

It occurs to me that for certain schemas particularly heavy in  
markup, like SVG whiteboarding, the compression potential is pretty  
high, but for quite a few typical uses of XMPP - like IM itself - the  
bulk of the compression will be down to DEFLATE anyway, suggesting  
that doing EXI in these cases isn't worthwhile - although I may be  
wrong here.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list