[Standards] Stream Compression: When to advertise and allow compression? XEP unclear and clonflicting with itself.

Tobias Markmann tmarkmann at googlemail.com
Tue Aug 18 17:41:37 UTC 2009

First of all I wonder what's the reason to allow stream compression only
after SASL and before binding. XEP-0170 [1] says it's that way to prevent
certain denial of service attacks but doesn't clarify it any further. So I'm
asking myself what kind of attacks that are. Because some clients and
servers, which implemented stream compression before XEP-0170 was there do
compression only before SASL.

Secondly, XEP-138 [2] says,

> Because negotiation of stream compression should not be completed after
> application of any encryption layers and because SASL negotiation (see RFC
> 3920) may involve application of an encryption layer, stream compression
> SHOULD be negotiated after SASL negotiation. For detailed recommendations
> regarding the order of stream feature negotiation, refer to Recommended
> Order of Stream Feature Negotiation [4].

in its Business Rules section. The first sentence contradicts the second
one. The first disallows the use of stream compression when an encryption
layer is present however the second, forwarding to XEP-170, precisely
describes when to allow stream compression even after TLS has be negotiated.

[1] http://xmpp.org/extensions/xep-0170.html#c2s-compress
[2] http://xmpp.org/extensions/xep-0138.html#bizrules

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090818/01afa6c8/attachment.html>

More information about the Standards mailing list