Tomas Karasek wrote:
Hi everyone,I was talking about $SUBJ with Safa, the thing is - What should be the correct client's behaviour after Connection Manager sends <body> with <success> on successful SASL auth. XEP 0206 says client SHOULD send <body> with "to" and "xmpp:restart" attributes to CM, CM sends <stream:stream> to server and after receiving stream init response from XMPP server, CM "SHOULD forward any available features (or an empty element) to the client".Now I'll be addressing client <-> CM traffic only. How I got to it is that Openfire built-in CM doesn't reply on <body> with "xmpp:restart" attr. It just acts like the BOSH session is already/still open, so ther is no need to send <body> with xmpp:restart. Resource bind or whatever can immediately follow.On contrary, the ejabberd built-in CM demands <body> with xmpp:restart - if nonempty <body> without xmpp:restart follows after SASL <success> it answers with <body type=terminate> and session is over. However it replies on xmpp:restart like in the XEP and then session can continue - it even advertises some features in <stream:stream>.Long story short, ejabberd follows the scenario in XEP 0206, Openfire doesn't need/do examples 10 and 11 (but those steps are conditioned by SHOULD):http://www.xmpp.org/extensions/xep-0206.html#preconditions-sasl
I think SHOULD is wrong here and that it needs to be MUST.
So what is the correct behaviour after SASL auth?I'm for the ejabberd way, stream restart after SASL IMO should happen - as for plain XMPP, there is a MUST (not SHOULD) in RFC 3290:[...]Upon receiving the <success/> element, the initiating entity MUST initiate a new stream by sending an opening XML stream header to the receiving entity (it is not necessary to send a closing </stream> tag first, since the receiving entity and initiating entity MUST consider the original stream to be closed upon sending or receiving the <success/> element). Upon receiving the new stream header from the initiating entity, the receiving entity MUST respond by sending a new XML stream header to the initiating entity, along with any available features[...]
Yes, that's a good reason to make it a MUST in XEP-0206. I wonder if Ian made it a SHOULD for backward-compatibility? (IIRC the 'restart' attribute was added in XEP-0206 and was not in the old XEP-0124.)
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
