Le 17/12/2009 23:02, Alexander Tsvyashchenko a écrit :
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.
Yep ok you're right, there are pushes, and PEP is born after this XEP,
maybe for a future version of this XEP :)
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 ;-)
Right, I didn't thought about those possibilities. Thanks for
clarifications.
"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.
Ok ok I completly missunderstood what OTR means. I thought it was an
encryption method. So after reading this part, I understand the
negotiation, and it should indeed be used when using encrypted sessions
or GPG, as if OTR option was set to "require".
[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.]
Great news !! Thanks
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'.
Yep, but at the end of the session, should we remove the <item> or not?
If if was there before the session, no we should not, if it wasn't, we
should. And if there was a rule saying save='true' we loose this
preference when we replace it with the save='false' rule.
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?
[...] (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 ;-)
it's a security issue because if the connection or client crashes before
we remove it, we stored a chat that we agreed to not store.
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.
GPG chat are quite common, no?
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='[email protected]' save='false'/> to disable
server-side
auto-archiving for particular session.
hmm I'm not sure it's a good solution, because a session is not a jid. I
technically have 2 sessions open with a jid, one that I want to log, and
one not. And those optins should not be saved permanently on server,
because it's a temporary preference. I may want to archive next session
with this jid.
* 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.
I think that can cover what clients need: If negociation say to not log
the conversation, we add a rule with the full jid, scope=session and
save=false, but from a server point of view, it will be hard to guess
then a chat session will end. Will it have to check all messages and
check that thread id won't change?
What about what I proposed earlier:
we use the stanza from example 48:
<iq type='set' id='remove6'>
<remove xmlns='urn:xmpp:archive'
with='[email protected]/chamber'
open='true'/>
</iq>
And we add in the spec that once this stanza is sent, server stops
archiving conversation with this JID (maybe it would be easier for
server to add a <thread> element to the request, so that it's easier for
server to trace which session messages belongs to).
This way clients don't have to deal with those <item> things, and that
doesn't change anything for the server, it have to remember this
temporary rule.
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.
if I set <auto save='true'/> that already mean that autoarchiving is
turned on permanently, no?
--
Yann
