Matthew Wild wrote:
On Mon, Jul 28, 2008 at 3:14 AM, Peter Saint-Andre <[EMAIL PROTECTED]> 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
smime.p7s
Description: S/MIME Cryptographic Signature
