[Standards] certification etc.
dave at cridland.net
Thu Mar 29 15:26:03 UTC 2007
On Thu Mar 29 02:24:11 2007, Peter Saint-Andre wrote:
> Right. Unfortunately, it seems that some (many? most?) TLS
> implementations do not support the compression option, so even if
> the XMPP client and XMPP server support TLS, if their underlying
> TLS library lacks support for compression there's not much they can
This debate came up in Lemonade, since Lemonade introduces
application level stream compression too. The summary is that on many
devices that would benefit from compression, such as mobile handsets,
the Nokia Internet Tablets, etc, there's no inherent ability for
compression. However, there are third-party plugins available for
both the older OpenSSL 0.9.7 that's in use on the tablets, and for
In addition to the above, being able to distinguish from a flush
through the compression algorithm, and a flush through TLS and the
network, means that higher compression can be achieved in some cases.
This probably doesn't apply to XMPP, since the data is relatively
uniform from a formatting perspective, whereas in IMAP the switch
between the protocol and the payload data can skew statistical
compressors (such as the Huffman stage of DEFLATE) very heavily.
There overall consensus was that application-level stream compression
is useful at least in the short term, although the better long-term
strategy is to use TLS compression and "fix" the APIs.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards