[Standards] XEP-0138 vs. TLS compression

Tobias Markmann tmarkmann at googlemail.com
Tue Aug 28 22:05:30 UTC 2007


It should offer stream compression anyway since its own support for TLS
compression doesn't help a lot if the connecting server doesn't support it
or has it implemented otherwise. Like the openssl page said, compression is
not described in the RFC so it's up to the implementations to deal with it
and I doubt that OpenSSL,, GNUTLS, Windows SSPI, etc. are compatible to each
other.

Tobias Markmann

On 8/29/07, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>
> 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
> >
> > NOTES
> > 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
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070829/1df414f4/attachment.html>


More information about the Standards mailing list