Hum, as this 'xmpp:restart' thingy was my idea more or less, maybe I should comment on this a little bit.
The reason why it exists is, that a connection manager shouldn't need to know anything about the state of the underlying stream. Thus it should only handle the wrapping BOSH session layer (the body element) and should need to parse and "understand" the wrapped content (payload). The only thing it needs to do is initiate a stream. Amongst others tt shouldn't have to care about negotiation stuff between the client and the server. Thus it can't know when to reinitiate a new stream as it may be required by things like XMPP's SASL auth. So there is a need for the client to be able to indicate this to the CM. As the client can't know whether the CM handles reinitialization automatically (like openfire or maybe punjab are doing) it indeed MUST include the xmpp:restart attribute as otherwise with a 'dumb' CM it couldn't proceed correctly at this point. Cheers, Steve Am Mittwoch, den 16.07.2008, 00:57 +0200 schrieb Tomas Karasek: > 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 >
