Jonathan Schleifer wrote: > 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. [...] > The client did that before, but it changed while sending. We got a > race condition here.
Ok, we have a race condition here for some seconds and the sender already send the message before receiving the new capabilities. In that case the receiver gets an IBB with an unknwon sid and sends an error. It does not know that it is part of an e2e so it can not inform the user. Only the sender can detect this problem. > It helps the sender to know that something went wrong, but not the > receiver. The the race condition I mentioned above. Why do you want to inform the receiver? He can not do anything about the problem. It is the sender who has to fix it by either re-open the e2e stream with the new client and resend the message or if that is not possible (the new client has no e2e support) it should inform the sender about the problem suggesting an insecure resend. If the user does not want to use insecure communication, the client may drop the message. Anyway, IF you want to inform the receiver, the sender could generate a new message 'e2e stream broken, message not delivered' and send it to the receiver. Dirk -- "There is no reason for any individual to have a computer in their home." (Ken Olsen, Präsident von DEC, 1977)
