View Full Version : [BOSH] stream restart after SASL auth in BOSH
Tomas Karasek
07-16-2008, 12:59 AM
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
Peter Saint-Andre
07-16-2008, 05:02 PM
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
Hi all, I am working on this issue and have some questions. Can the
xmpp:restart body be non-empty? For example, emite sends the bind request
within the body containing xmpp:restart.
If the answer to the previous question is yes, would it be correct to
include both stream features and the bind result in the same response body?
--
Safa
Peter Saint-Andre
07-22-2008, 09:09 AM
Safa wrote:
> Hi all, I am working on this issue and have some questions. Can the
> xmpp:restart body be non-empty?
I'm not sure. I would consider Ian Paterson to be the canonical
authority regarding BOSH, except that it seems he has dropped off the
face of the earth. Therefore I think it's up to us to figure out what's
right and what's wrong.
But to answer your question, I think not that behavior is potentially
problematic, because stream restart means "consider anything I send
after this to be null and void, since the old stream is gone". I suppose
the connection manager could cache the <body/> and send it over the new
stream, but I think it's better not to send anything until you receive
notification that the new stream is up and running.
> For example, emite sends the bind
> request within the body containing xmpp:restart.
I don't think that's right, but I can't say so with 100% confidence.
> If the answer to the previous question is yes, would it be correct to
> include both stream features and the bind result in the same response body?
If so, yes.
How many roundtrips / bytes does this save? Is it worth the bother?
/psa
Stefan Strigler
07-23-2008, 11:48 AM
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
>
Stefan Strigler
07-23-2008, 12:03 PM
Hi,
Am Freitag, den 18.07.2008, 22:16 +0300 schrieb Safa:
> Hi all, I am working on this issue and have some questions. Can the
> xmpp:restart body be non-empty? For example, emite sends the bind
> request within the body containing xmpp:restart.
>
> If the answer to the previous question is yes, would it be correct to
> include both stream features and the bind result in the same response
> body?
Unfortunately the XEP is not clear about that.
In my implementations the CM's forwards the enclosed payload to the new
stream. I think it should be safe to assume a successful
reinitialization of the new stream and thus allow a non-empty body with
the xmpp-restart behaviour.
The response should contain the stream features plus results of the
request if any (although I'm aware of the fact that maybe a stream bind
has been tried without the according stream feature given). I'd say it's
up to you (the client) to handle this situation. If you don't want to
take the risk, don't do it.
Cheers, Steve
Thanks, that was really helpful.
2008/7/23 Stefan Strigler <steve (AT) zeank (DOT) in-berlin.de>:
> Hi,
>
> Am Freitag, den 18.07.2008, 22:16 +0300 schrieb Safa:
> > Hi all, I am working on this issue and have some questions. Can the
> > xmpp:restart body be non-empty? For example, emite sends the bind
> > request within the body containing xmpp:restart.
> >
> > If the answer to the previous question is yes, would it be correct to
> > include both stream features and the bind result in the same response
> > body?
>
> Unfortunately the XEP is not clear about that.
> In my implementations the CM's forwards the enclosed payload to the new
> stream. I think it should be safe to assume a successful
> reinitialization of the new stream and thus allow a non-empty body with
> the xmpp-restart behaviour.
> The response should contain the stream features plus results of the
> request if any (although I'm aware of the fact that maybe a stream bind
> has been tried without the according stream feature given). I'd say it's
> up to you (the client) to handle this situation. If you don't want to
> take the risk, don't do it.
>
> Cheers, Steve
>
>
--
Safa
Peter Saint-Andre
07-28-2008, 04:10 AM
Hi Stefan, thanks for the clarification.
Given that the client has no way of knowing if the CM will be smart, why
not say that the client MUST (not SHOULD) send the xmpp:restart?
/psa
Stefan Strigler wrote:
> 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
>>
>
Peter Saint-Andre
07-28-2008, 04:16 AM
Stefan Strigler wrote:
> Hi,
>
> Am Freitag, den 18.07.2008, 22:16 +0300 schrieb Safa:
>> Hi all, I am working on this issue and have some questions. Can the
>> xmpp:restart body be non-empty? For example, emite sends the bind
>> request within the body containing xmpp:restart.
>>
>> If the answer to the previous question is yes, would it be correct to
>> include both stream features and the bind result in the same response
>> body?
>
> Unfortunately the XEP is not clear about that.
So let's make it clear. :)
> In my implementations the CM's forwards the enclosed payload to the new
> stream. I think it should be safe to assume a successful
> reinitialization of the new stream and thus allow a non-empty body with
> the xmpp-restart behaviour.
That seems reasonable. IMHO it is unlikely that the stream restart will
fail (see rfc3920bis). But see below.
> The response should contain the stream features plus results of the
> request if any (although I'm aware of the fact that maybe a stream bind
> has been tried without the according stream feature given). I'd say it's
> up to you (the client) to handle this situation. If you don't want to
> take the risk, don't do it.
Right, it's possible that the server won't advertise support for
resource binding (or whatever). So the most careful approach would be to
wait for the server to sends its features, then negotiate whatever is
required. But that means an extra round trip.
I don't have a strong feeling about this, but I'd like to clearly
specify it in the XEP.
/psa
Matthew Wild
07-28-2008, 01:47 PM
On Mon, Jul 28, 2008 at 3:14 AM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
> Stefan Strigler wrote:
>>
>> Hi,
>>
>> Am Freitag, den 18.07.2008, 22:16 +0300 schrieb Safa:
>>>
>>> Hi all, I am working on this issue and have some questions. Can the
>>> xmpp:restart body be non-empty? For example, emite sends the bind
>>> request within the body containing xmpp:restart.
>>>
>>> If the answer to the previous question is yes, would it be correct to
>>> include both stream features and the bind result in the same response
>>> body?
>>
>> Unfortunately the XEP is not clear about that.
>
> So let's make it clear. :)
>
>> In my implementations the CM's forwards the enclosed payload to the new
>> stream. I think it should be safe to assume a successful
>> reinitialization of the new stream and thus allow a non-empty body with
>> the xmpp-restart behaviour.
>
> That seems reasonable. IMHO it is unlikely that the stream restart will fail
> (see rfc3920bis). But see below.
>
>> The response should contain the stream features plus results of the
>> request if any (although I'm aware of the fact that maybe a stream bind
>> has been tried without the according stream feature given). I'd say it's
>> up to you (the client) to handle this situation. If you don't want to
>> take the risk, don't do it.
>
> Right, it's possible that the server won't advertise support for resource
> binding (or whatever). So the most careful approach would be to wait for the
> server to sends its features, then negotiate whatever is required. But that
> means an extra round trip.
>
> I don't have a strong feeling about this, but I'd like to clearly specify it
> in the XEP.
>
It goes against logic to send the bind request before the stream
features. As long as it can always be done the "proper" way then I see
no harm in allowing this hack, however. Faster logins can't be a bad
thing. :)
Matthew
Peter Saint-Andre
07-28-2008, 04:01 PM
Matthew Wild wrote:
> On Mon, Jul 28, 2008 at 3:14 AM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
>> Stefan Strigler wrote:
>>> Hi,
>>>
>>> Am Freitag, den 18.07.2008, 22:16 +0300 schrieb Safa:
>>>> Hi all, I am working on this issue and have some questions. Can the
>>>> xmpp:restart body be non-empty? For example, emite sends the bind
>>>> request within the body containing xmpp:restart.
>>>>
>>>> If the answer to the previous question is yes, would it be correct to
>>>> include both stream features and the bind result in the same response
>>>> body?
>>> Unfortunately the XEP is not clear about that.
>> So let's make it clear. :)
>>
>>> In my implementations the CM's forwards the enclosed payload to the new
>>> stream. I think it should be safe to assume a successful
>>> reinitialization of the new stream and thus allow a non-empty body with
>>> the xmpp-restart behaviour.
>> That seems reasonable. IMHO it is unlikely that the stream restart will fail
>> (see rfc3920bis). But see below.
>>
>>> The response should contain the stream features plus results of the
>>> request if any (although I'm aware of the fact that maybe a stream bind
>>> has been tried without the according stream feature given). I'd say it's
>>> up to you (the client) to handle this situation. If you don't want to
>>> take the risk, don't do it.
>> Right, it's possible that the server won't advertise support for resource
>> binding (or whatever). So the most careful approach would be to wait for the
>> server to sends its features, then negotiate whatever is required. But that
>> means an extra round trip.
>>
>> I don't have a strong feeling about this, but I'd like to clearly specify it
>> in the XEP.
>>
>
>
> It goes against logic to send the bind request before the stream
> features. As long as it can always be done the "proper" way then I see
> no harm in allowing this hack, however. Faster logins can't be a bad
> thing. :)
Right. Sending the bind request in the stream restart is a kind of
pipelining. We've talked about pipelining for the TCP binding too but
haven't documented that yet. For BOSH, pipelining forces the CM to keep
more state, but if CMs want to take on that responsibility then it makes
the client's life easier (simple clients, complex servers). However, if
we allow this then we need to spec out (1) how the client discovers if
the CM supports pipelining and (2) what error the CM returns if it does
not support pipelining but the client attempts pipelining. Or so it
seems to me.
Peter
Peter Saint-Andre
08-14-2008, 04:31 AM
Peter Saint-Andre wrote:
> Stefan Strigler wrote:
>> Hi,
>>
>> Am Freitag, den 18.07.2008, 22:16 +0300 schrieb Safa:
>>> Hi all, I am working on this issue and have some questions. Can the
>>> xmpp:restart body be non-empty? For example, emite sends the bind
>>> request within the body containing xmpp:restart.
>>>
>>> If the answer to the previous question is yes, would it be correct to
>>> include both stream features and the bind result in the same response
>>> body?
>>
>> Unfortunately the XEP is not clear about that.
>
> So let's make it clear. :)
>
>> In my implementations the CM's forwards the enclosed payload to the new
>> stream. I think it should be safe to assume a successful
>> reinitialization of the new stream and thus allow a non-empty body with
>> the xmpp-restart behaviour.
>
> That seems reasonable. IMHO it is unlikely that the stream restart will
> fail (see rfc3920bis). But see below.
>
>> The response should contain the stream features plus results of the
>> request if any (although I'm aware of the fact that maybe a stream bind
>> has been tried without the according stream feature given). I'd say it's
>> up to you (the client) to handle this situation. If you don't want to
>> take the risk, don't do it.
>
> Right, it's possible that the server won't advertise support for
> resource binding (or whatever). So the most careful approach would be to
> wait for the server to sends its features, then negotiate whatever is
> required. But that means an extra round trip.
>
> I don't have a strong feeling about this, but I'd like to clearly
> specify it in the XEP.
Seeing no further discussion, I suggest that we change the spec as follows:
Upon receiving the <success/> element, the client MUST then ask
the connection manager to restart the stream. It does this by
setting to "true" the 'xmpp:restart' attribute (qualified by the
'urn:xmpp:xbosh' namespace) of the BOSH <body/> element. When
sending the restart request, the client SHOULD also include the
'to' and 'xml:lang' attributes. In addition the <body/> SHOULD
be empty (if the client includes an XML stanza in the body, the
connection manager might send that stanza when the stream is
restarted, but there is no guarantee that a connection manager
will do so).
Objections?
Peter
Tomas Karasek
08-14-2008, 01:57 PM
Peter Saint-Andre wrote:
> Peter Saint-Andre wrote:
>> Stefan Strigler wrote:
>>> Hi,
>>>
>>> Am Freitag, den 18.07.2008, 22:16 +0300 schrieb Safa:
>>>> Hi all, I am working on this issue and have some questions. Can the
>>>> xmpp:restart body be non-empty? For example, emite sends the bind
>>>> request within the body containing xmpp:restart.
>>>>
>>>> If the answer to the previous question is yes, would it be correct to
>>>> include both stream features and the bind result in the same response
>>>> body?
>>>
>>> Unfortunately the XEP is not clear about that.
>>
>> So let's make it clear. :)
>>
>>> In my implementations the CM's forwards the enclosed payload to the new
>>> stream. I think it should be safe to assume a successful
>>> reinitialization of the new stream and thus allow a non-empty body with
>>> the xmpp-restart behaviour.
>>
>> That seems reasonable. IMHO it is unlikely that the stream restart
>> will fail (see rfc3920bis). But see below.
>>
>>> The response should contain the stream features plus results of the
>>> request if any (although I'm aware of the fact that maybe a stream bind
>>> has been tried without the according stream feature given). I'd say it's
>>> up to you (the client) to handle this situation. If you don't want to
>>> take the risk, don't do it.
>>
>> Right, it's possible that the server won't advertise support for
>> resource binding (or whatever). So the most careful approach would be
>> to wait for the server to sends its features, then negotiate whatever
>> is required. But that means an extra round trip.
>>
>> I don't have a strong feeling about this, but I'd like to clearly
>> specify it in the XEP.
>
> Seeing no further discussion, I suggest that we change the spec as follows:
>
> Upon receiving the <success/> element, the client MUST then ask
> the connection manager to restart the stream. It does this by
> setting to "true" the 'xmpp:restart' attribute (qualified by the
> 'urn:xmpp:xbosh' namespace) of the BOSH <body/> element. When
> sending the restart request, the client SHOULD also include the
> 'to' and 'xml:lang' attributes. In addition the <body/> SHOULD
> be empty (if the client includes an XML stanza in the body, the
> connection manager might send that stanza when the stream is
> restarted, but there is no guarantee that a connection manager
> will do so).
>
> Objections?
>
> Peter
>
Hi,
agreed. But what about the paragraph _below_ Example 10 in XEP-0206?
Shouldn't it say that
"Upon receiving the response from the XMPP server, it MUST <not SHOULD>
forward any available features (or an empty element) to the client"
to make the CM let client know about the stream restart? That way, it
would be safe for client to wait for the restart response and send bind
request only after it knows stream restart was successful. Moreover,
there can be new features which haven't been in init response.
IMO it's good to delay further actions after the stream restart because
it makes client behavior more clear and I think it can also help on CM
side - CM wouldn't have to deal with parallel bind request and body with
xmpp:restart. But it can slightly slow down the login process.
tomk
--
Tomas Karasek
jabber: tom.to.the.k at jabber.cz
GSoC blog: http://tomk-soc08.blogspot.com/
Peter Saint-Andre
08-14-2008, 06:18 PM
Tomas Karasek wrote:
> But what about the paragraph _below_ Example 10 in XEP-0206?
> Shouldn't it say that
>
> "Upon receiving the response from the XMPP server, it MUST <not SHOULD>
> forward any available features (or an empty element) to the client"
Yes, I had made that change, too, but I forgot to post about it.
> to make the CM let client know about the stream restart? That way, it
> would be safe for client to wait for the restart response and send bind
> request only after it knows stream restart was successful. Moreover,
> there can be new features which haven't been in init response.
>
> IMO it's good to delay further actions after the stream restart because
> it makes client behavior more clear and I think it can also help on CM
> side - CM wouldn't have to deal with parallel bind request and body with
> xmpp:restart. But it can slightly slow down the login process.
Yes, it can. That's why I want to make sure this change is acceptable to
people on this list.
Peter
vBulletin® v3.8.0 Release Candidate 2, Copyright ©2000-2009, Jelsoft Enterprises Ltd.