On Thu Apr 3 00:32:54 2008, Tobias Markmann wrote:
On Thu, Apr 3, 2008 at 1:22 AM, Dave Cridland <[EMAIL PROTECTED]>
wrote:
> On Wed Apr 2 23:22:12 2008, [EMAIL PROTECTED] wrote:
> 1) It's much simpler to implement, and2) Given that we are (or
should be)
> encrypting every S2S connection, then TLS is giving us
compression anyway,
> and moreover, it's cheaper to compress than not to compress.
That may be right from the spec but in real world it's a lot worse.
TLS
doesn't really give use compression anyway.
See this from the man page on SSL_COMP_add_compression_method(3)
(OpenSSL):
> 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.
> Applications for non-public use may agree on certain compression
methods.
> Using different compression methods with the same identifier will
lead to
> connection failure.
The only way to make use of TLS's compression capabilities is to
get all
XMPP servers and clients use the same compression methods and same
identifiers for those methods otherwise TLS just does NOT do
compression.
Since this seems very unlikely I prefer applying XEP-0138 and then
TLS.
OpenSSL has negotiated the DEFLATE compression codec defined in RFC
3749 since 0.9.8 came out - the documentation may be wrong, but it
always is with OpenSSL.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
