> No. The sender is not the problem, the sender can notice through XEP-0184 > that the message got lost or couldn't be decrypted. The problem is: When the > receiver receives a message at the wrong resource, he'll never know.
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). > know. However, when you add a body and that encrypted message goes to a > client not capable of E2E, the receiver *will* now. 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. > The message was directed to the resource, still, the routing problem did > happen. The routing rules are different for <message> than for <iq>. Messages can still be routed to other resources, iq's can't. > Plus we might have reconnected with another resource with the same > name, but other capabilities. As noted before, your client has to detect this (using Entity Capabilities for example). > IQ doesn't help at all 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. cheers, Remko
