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/
