[Standards] XEP-0138 vs. TLS compression

Fletcher, Boyd C. CIV US USJFCOM JFL J9935 Boyd.Fletcher at je.jfcom.mil
Wed Aug 29 13:00:38 UTC 2007

Speaking of compression, I think we should consider adding the w3's efficient xml interchange (exi) support to xep-138. The testing results I've seen for EXI indicate that in many circumstances it is quite a bit better than zlib or tls compression. In addition to better b/w utilization use of exi within the xmpp router could potentially lead to dramatically improved scalability as binary xml is far more efficient to process.


Boyd Fletcher
M: 757.535.8190 (GSM)
M: 757.771.7084 (BB)
Sent from my BlackBerry so please excuse my typos.

-----Original Message-----
From: standards-bounces at xmpp.org <standards-bounces at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>
Sent: Tue Aug 28 18:01:07 2007
Subject: Re: [Standards] XEP-0138 vs. TLS compression

Tomasz Sterna wrote:
> While implementing XEP-0138 for jabberd2 I have discovered the following
> note:
> http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html
> The TLS standard (or SSLv3) allows the integration of compression
> methods into the communication. The TLS RFC does however not specify
> compression methods or their corresponding identifiers, so there is
> currently no compatible way to integrate compression with unknown peers.
> It is therefore currently not recommended to integrate compression into
> applications. [...]
> This makes all our notes about using TLS compression and the order of
> TLS and XEP-0138 at least questionable, don't it?

I don't think it invalidates our recommendation to do TLS, then SASL,
then compression. However, if the server implementation doesn't have
compression support in its underlying TLS library then it should offer
and allow stream compression via XEP-0138.

Or so it seems to me.


Peter Saint-Andre

More information about the Standards mailing list