Alexander Tsvyashchenko <[email protected]> a écrit :
Ok, but if we cannot expect clients to handle things as simple as timeout value properly - chances that they implement OTR correctly at all are close to zero, and that would be much more serious problem ;-) Speaking seriously, the problem is that we cannot rely on client/recipient logging off to clean temporary prefs - what if they both remain connected indefinitely? (f.e. they're bots/services, or just do not have a habit to ever turn off computers) Preferences would grow then with each conversation without any possibility for the server to clean them, finally causing DoS. Additionally, I do not really like the idea of archiving server parsing all presences stanzas just to track recipient log off event.
Ok I understand. It's not a very nice solution indeed.
As a somewhat "safer" solution we might treat timeout value not as "time from the prefs set to prefs expiration", but as "time from the last message sent/received during conversation to prefs expiration" - then, having this value set to meaningfully large value will in most cases ensure that prefs cannot be removed while conversation is still active.
Hmmm yep sounds nice, but I guess server won't send a new IQ saying the new timeout at every message exchanged. So client won't know exactly when they have to re-send the "hoho don't log this session" IQ. Sure client could remember the value of the timeout server sent the first time, and restart to count at each message, but server may behave differently that client: chatstates message will restart counter on server, but mybe not in clients ...
So maybe it's the best solution, but XEP have to be precise on what makes the counter re-start.
-- Yann ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
