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
smime.p7s
Description: S/MIME Cryptographic Signature
