Alexander Tsvyashchenko wrote: > On Fri, 18 Dec 2009 10:20:21 +0100, Yann Leboulanger <[email protected]> > wrote: >> But a solution could be that when we send a request to removing a >> collection being recorded by the server (example 48) The server should >> stop recording this session automatically, don't you think it could be >> added to the spec? > > I think that might cover typical use cases, but might lead to problems in > some (not really common, though?) scenarios. > > Suppose client negotiated OTR with some contact (due to E2E, GPG, or > whatever reason), so it sent <remove jid='..' open='true'/> to the server > and server remembered that it should not record messages for conversations > with this contact during current session/conversation/stream (see below for > terms discussion) anymore. > > Now, client during the same session/conversation/stream renegotiates > parameters to not use OTR (f.e. they do not discuss anything secret anymore > so they do not use E2E/GPG, or whatever else reason) - but client cannot > use auto-archiving with this contact anymore because it can only disable it > via <remove> command and has no way to enable it back other than > closing/reopening session/conversation/stream.
hmm indeed, in this case I see 2 solutions: - The solution you propose: closing / reopening - add 2 new <iq> commands: Stop logging and re-start logging > 1) "Session" was bad term here, sorry about that :-( What you mean by > "session" is most likely session in XEP-155 sense, right? What I meant was > "stream" (= "XMPP stream between client and server"). Also note that > "session" is not the "set of messages between client and contact forming > single collection" - that is called "conversation" in XEP-136 and is wider > than "session" because it might contain messages which are not part of any > formally negotiated session and even lack common <thread> element. Yep for me session was chat session as in XEP-155 > 2) <auto> setting in current XEP-136 spec applies to stream, it is not > stored permanently, so its value is lost when stream is re-opened, see > section 6, after "Otherwise:" words. That's not the case in your ejabberd module :) but ok. So client have to set auto to true if if save attribute default element if != false. Why force client doing that? Clients have no way to tell their server to always do auto-archiving? > What you seem to imply here and below is that you'd like to have finer > control for auto archiving than at level "stream + contacts" - you'd like > to control things at session/conversation + contacts level, did I > understand you correctly? Yes exactly. > While some scenarios certainly could benefit from that, personally for me > it looks like complicating things too much: many clients still lack support > even for <thread> element (not even speaking of session negotiations), so > it's not clear at all how to define and reference different conversations > to manage auto-archiving for them. ok, but in this case I don't see how my client ould implement this XEP. It supports E2E and GPG, so I don't see how to tell server to not store those encrypted messages, but store unencrypted messages with those same contacts. Adding the <item> elements is a workaround, not a solution, we agree on that. And ok some clients don't support <thread> nor session negotiation, but in this case they cannot support the OTR negotiation of this XEP, so I don't see the problem for the server to track those conversations when <thread> element is present.
