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. :) Matthew
