Yann, On Sun, 20 Dec 2009 21:58:03 +0100, Yann Le Boulanger <[email protected]> wrote:
[skipped] >> The only (?) remaining problem then is the way to expire these settings >> while stream is still open. >> >> We could require the server to intercept session negotiations and remove >> these settings when session is closed (as server already has to intercept >> all messages for the purposes of auto-archiving that should not be a big >> deal), but that would mean that server should understand XEP-0155 and >> also >> would not work for conversations not using XEP-0155 and using <thread> >> only. > > And sessions may not be corrcetly closed by clients. So I don't think > it's a very good solution. That would leak servers with bad clients. Yes, additionally it's not going to work for <thread>-only capable clients anyway (who cannot perform full session negotiation) so I listed it here just for completeness and to contrast it with another solution ;-) >> Therefore it looks like the better solution would be just to use timeouts >> for these settings in the way similar to this one: >> 1. Client sends to the server <auto thread='..' save='false'/> (or >> save='body', or whatever it needs). >> 2. Server performs prefs push to all connected clients with something >> like <auto thread='..' save='false' expire='..' /> where 'expire' means >> how >> long the server will keep this temporary setting. We might call it >> differently, though, to avoid confusion with <item> 'expire' attribute - >> maybe 'timeout' would be better? > > I'm not sure it's nice because it's not very safe, if conversation > lasts longer and clients don't handle the timeout value, server will > save data that it should not. Server could just check when the > resource of this thread logs off, no? 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. 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. Of course, it still requires clients to implement timeout tracking, but decreases chances of nasty things happening if they fail to do so properly. What do you think? -- Good luck! Alexander
