Am 30.09.2008 um 16:53 schrieb Remko Tronçon:
As Dirk said, an <iq> cannot be delivered to the wrong resource, unless there is a bug in the server (which is not a case you should be trying to solve anyway).
Wrong. It can. You have client A and client B installed. Both have the same resource configured. Client A can handle it, client B can't. Client B connectes and kicks client A. Tada, you got the problem.
A client shouldn't have sent an encrypted packet in the first place to a client that is not supporting it. That's a bug in the sending client.
See the situation above. It is perfectly fine for the client to send.
The routing rules are different for <message> than for <iq>. Messages can still be routed to other resources, iq's can't.
Which doesn't help in the above example.
As noted before, your client has to detect this (using Entity Capabilities for example).
The client did that before, but it changed while sending. We got a race condition here.
It does, and in more than just the routing. I think IBB using <messages> is a bad thing, both for routing and for control. I'm not sure why this approach is still described in the IBB spec.
It helps the sender to know that something went wrong, but not the receiver. The the race condition I mentioned above.
-- Jonathan -- Jonathan
PGP.sig
Description: This is a digitally signed message part
