Re: [Standards] XEP-0170: Recommended Order of Stream Feature Negotiation
On 2014-04-29 18:12, Kim Alvefur wrote: does not mention XEP 198, Stream Management. 198 does point to 170 however. [...] it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. But for c2s connection that is after resource binding, so the offer needs to be after the SASL restart. Further issues, section 3.3 in the Dialback scenario. The recommendation is to enable Compression after Dialback, but there is no stream restart and no features after Dialback, which complicates things. http://xmpp.org/extensions/xep-0170.html#s2s-compress -- Kim Zash Alvefur signature.asc Description: OpenPGP digital signature
Re: [Standards] XEP-0170: Recommended Order of Stream Feature Negotiation
On Apr 29, 2014, at 9:12 AM, Kim Alvefur z...@zash.se wrote: Hello list, I noticed that XEP-0170 1) talks about the old RFCs and 2) does not mention XEP 198, Stream Management. 198 doesn't use a stream restart, so some description about that could be useful. Is it perhaps time for an update to this XEP (or replacement)? -- Kim Zash Alvefur I'm +1 for reviewing and updating XEP-0170. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] XEP-0170 Recommended Order of Stream Feature Negotiation
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
