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. Regards, Mridul 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
