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
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
[...]
Regards,
Tomas Karasek
