Alexander Tsvyashchenko wrote: > Hello Yann, > > On Thu, 17 Dec 2009 17:28:22 +0100, Yann Le Boulanger > <[email protected]> wrote: > > [skipped] >> First, the preferences: >> I don't see the difference between >> <auto save='false'/> >> and >> <method type='auto' use='forbid'/> >> in example 3. > [skipped] >> the <auto> is for the server (and it's the only parameter that server >> looks at) and <method> element is only a sort of storage place for >> client used only when negociating a session? But in that case Why >> having 3 methods? Because in stanza negociation we only negociate ONE >> parameter: logging, that doesn't tell if we are negiciating >> server-side automatic logging or server-side manual logging or local >> logging. > > 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. And I still don't understand what <method type='auto' use='forbid'/> mean if I also set <auto save='true'/>. Also if we set that in preferences: <auto save='true'/> <default otr='concede' save='false'/> this mean we enable autoarchiving, but we save .. nothing?? Isn't that way of handling preferences very very complexe? Or I don't understand things correcly? > (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. >> Second point: what to do after a negociation. Imagine I have automatic >> logging set to on. I start chatting, so messages are logged on my >> server and locally. In the same time, I negociate a session with this >> contact, and the result is that he doesn't want me to log the >> conversation. So ok I remove logs on my local database, no problem, >> than I have to tell the server to remove logs, no problem, it's >> defined in this XEP, but I also have to tell him to stop logging this >> particular session. How do I do that? I don't want to disable >> automatic logging with other contacts, only with this particular >> contact in this particular session. > > 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!! > You can either add to archiving prefs the item for this particular contact > with save='false' (such as <item jid='[email protected]' 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. > In fact I never really understood the whole idea of having OTR in XEP-136 > in the first place: my belief is that it's as useful as barrier in this > well-known picture: > http://www.syslog.com/~jwilson/pics-i-like/kurios119.jpg - IMHO just saying > "Please, don't tell it to anyone!" is as efficient (if not better) as the > whole OTR part of XEP-136 ;-) Therefore I've never tried to really analyse > any archiving scenarios involving OTR, and it's quite possible there are a > lot of other inconsistencies there. > > 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? -- Yann
