[Standards] XEP-0170 Recommended Order of Stream Feature Negotiation

Mridul Mridul.Muralidharan at Sun.COM
Thu Aug 16 09:15:46 UTC 2007

You can get sasl to provide the means to establish an encrypted channel
after authentication (digest-md5 for example) - which is the reason to
establish compression after sasl.
Since we already have tls, I dont know what sort of value add it would
provide in xmpp case ... but the order of feature negotiation is based
on the assumption that this could be leveraged sometimes in the future
(like when tls cant be used, etc), and it would be the right order.

iirc xep 170 is based on more recent feedback and discussions than 138
... it is possible that not many servers would have moved to it already,
and so the issues you observed.


Mats Bengtsson wrote:
> FYI:
> Since there is (was) conflicting recommendations in XEP-0170,
> Recommended Order of Stream Feature Negotiation,
> (SASL -> compression)
> and XEP-0138, Stream Compression, (compression -> SASL), but St Peter
> said 0170 is the correct one, I thought about investigating what servers
> say:
> OpenFire 3.3.2: It accepts both ways but continue to offer SASL even
> after the process SASL -> compress
>                     which it shouldn't
> ejabberd 1.1.2: It only accepts compression before SASL (XEP-0138)
> Mats

More information about the Standards mailing list