Yann, On Thu, 17 Dec 2009 21:18:37 +0100, Yann Leboulanger <aste...@lagaule.org> wrote:
[skipped] >> See "2.7 Server Archiving Preferences Interpretation" section, it was >> added exactly to clarify these kinds of confusions ;-) Your understanding >> is correct: <auto> is for the server and <method> is for client(s). > > Yep I saw this section after starting the mail, it's why I added this > paragraph ;) > But in this case, <method> elements are preferences set by clients for > clients, wouldn't it be better if it was saved using PEP? This way other > resources could know about the changes instantly and not at next > connection. Other resources do know about the changes instantly - see "push" examples 7, 10, 15. Having said that, I still agree that there might be better ways of doing things here: not sure why it was designed that way, but this XEP is comparably old - probably some of the more elegant solutions were not yet available when its first version was designed. > And I still don't understand what <method type='auto' use='forbid'/> > mean if I also set <auto save='true'/>. That client default preferences say "auto archiving should not be used", but due to some reason (f.e. explicit user request to auto-archive messages for this particular session, use of web-based client that cannot keep history locally or whatever) this default setting was overridden. > Also if we set that in preferences: > <auto save='true'/> > <default otr='concede' save='false'/> > this mean we enable autoarchiving, but we save .. nothing?? Not necessarily: this can be used to disable auto archiving by default, but still enable it for some contacts (or groups of contacts) via <item jid='...' save='body'/> prefs. > Isn't that way of handling preferences very very complexe? Or I don't > understand things correcly? Both? ;-) Again, see above - I agree things might be done here not in the best way, so I'm not trying to defend this approach - I'm just trying to explain what, in my opinion, current spec means ;-) >> (Note: I assume that by "used only when negotiating a session" you mean >> off-the-record negotiations, as there's no negotiation other than that >> related to archiving, I believe) > > hmmm no, I was more thing about encrypted session negociation, in which > you also negociate if you are allowed to archive or not the > conversation. I know nothing about OTR, so I just ignored this part of > the spec, and your ejabberd module don't implement that anyway. "in which you also negociate if you are allowed to archive or not the conversation" - mmm, sounds exactly what OTR (XEP 136 section 3 and especially 3.1) is about, no? Also note that current XEP-136 version does not specify any server responsibilities regarding OTR, so nor mine ejabberd module, neither smb else should contain anything related to OTR. [Offtopic: I've recently rewritten mod_archive_odbc from scratch to support both RDMBSes and mnesia via unified storage layer, use current XEP-136 version and work with exmpp-based ejabberd 3.x, but haven't managed yet to make it public as there are still things to improve - not that important, though, until ejabberd 3.x goes into at least beta, I think ... It's just to note that currently available mod_archive_odbc version is certainly not the best regarding current XEP-136 version conformance, new version will be (much?) better.] >> I believe current spec does not allow disabling auto-archiving for >> particular contact + particular session :-( > > This is a big issue, and automatic archiving is almost impossible for > client that implement E2E (like Gajim) or every client that implements > GPG (nearly all jabber clients), or all clients that will implement the > XTLS encrupted session in the future!! In most these cases just putting <item jid='...' save='false'> in prefs should be fine: it's unlikely people would constantly switch E2E or GPG on and off between different sessions with the same client, so just disabling auto-archiving for them should be OK. However, I agree it's rather 'workaround', not a 'solution'. >> You can either add to archiving prefs the item for this particular >> contact >> with save='false' (such as <item jid='ro...@montague.net' >> save='false'/>), >> but that would block all automatic archiving for this contact, not for >> particular session only - or you can issue <auto save='false'/>, that >> would >> work for current session only - but you've right that it would block all >> automatic archiving, not only for this contact. (Or you can just issue >> <remove> command at the end of conversation, but it looks like a hacky >> way >> of doing things) > > Indeed the last solution is not a good idea at all and is a big security > issue. First one is the less annoying workaround, but isn't a good > solution I think. Not really sure why the last solution is bigger security issue than passing unencrypted messages via the server in the first place, but that probably depends on what you mean by 'security issue' here (no objections to "not a good idea" part, though ;-) [skipped] >> If you think it's important, though, I think it's worth to come up with >> the idea on how to modify the spec to allow that scenario and post it >> here >> for discussion ;-) > > I think the OTR scenario is the same as the GPG scenario. If you cannot > stop archiving a session, you'll end up with a lot of messages like > [This message is encrypted] in the server archives. > I think there must be a way to modify the session archiving preferences. > You start chatting and negociate the session in the same time, and if > negociation conclusion is "Do no archive on server" then we have to be > able to tell the server to stop archiving this particular session (with > the session id most probably) > > What do you think? Yes, I'm all for it - I do not argue that there might be scenarios where it can be important, it's just that I haven't encountered them myself, so I had no real interest in diving deeper here. Just several quick ideas on how it could be implemented (please give your ideas also!): * Allow having several <auto> elements with additional 'jid' attribute, such as <auto jid='ro...@example.com' save='false'/> to disable server-side auto-archiving for particular session. * Allow <item> element to have a 'scope' attribute with possible values 'global' and 'session', and those with scope='session' should be discarded as soon as session is closed, while 'global' ones behave exactly like they do now. Personally I like the approach with 'scope' attribute more because I was going to suggest adding it to spec for <auto> element anyway, so that auto-archiving mode could be turned on persistently rather than for current session only. Please comment! -- Good luck! Alexander
