[Standards-JIG] Thought about serverside messages archives
stpeter at jabber.org
Mon Apr 17 18:05:35 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Ian Paterson wrote:
> Justin wrote:
>> You're right. What is missing from JEP-0136 is a way to determine
>> if the server is automatically logging messages, and possibly a way
>> to toggle the feature on/off. If server logging is enabled, then
>> the client would not have to upload messages.
> Yes. Autoarchiving needs to be merged into JEP-0136. This has been on my
> project list since the March 23rd council meeting, but I will have no
> time to work on it until the middle of May.
It's on my list for this week to merge the serverarchiving proposal from
the inbox into JEP-0136. I'll put out a preliminary version first to
make sure it meets with the approval of all authors first.
> Oliver wrote:
>> "Server-Side Message Archiving" proto-JEP uses an <iq> way to
>> configure the server. but IMO, the right way is to use JEP-0050
>> (Ad-Hoc Commands)... So client that support JEP-0050
>> automatically support toggling message archive.
I'm not sure. It's not a bad idea, but it doesn't feel ad-hoc anymore.
Same for invisibility (yes, it could be done with ad-hoc commands, but
then so could roster retrieval and everything else under the sun :-).
> We will need new server-side search features too (searching on subject
> and/or content). Do we want anything more than a simple word or phrase
> search? If so then IMO Archive Search should be a separate JEP that
> builds on JEP-0136. Jon Perlow might be in a very good position to
> author that. ;-)
>> I'd like to see [archiving] implemented in server as soon as possible
> Yes! IMO the only barrier to pushing JEP-0136 quickly to draft is the
> difficulty of the encryption section. Perhaps that could be separated
> out into another JEP too?
Probably. But then we don't have everything in one place, which was the
impetus behind folding serverarchiving into JEP-0136. But given that
it's unlikely people will agree on encryption methods any time soon (if
ever!), it's probably the best approach.
>> push messages back to a server is good if we want
>> to push messages on another archive server
> Yes. The Push Archiving approach even enables multi-protocol clients to
> store out-of-band messages, like email, as well.
> Push Archiving also avoids the disastrous (for some people) security
> implications of Autoarchiving.
Naturally the client needs to make that clear to the end user. But often
the end user doesn't really care. Sad but true.
> [IMO we have a responsibility to care
> about this - even Microsoft understands security is important now.]
Do they really? ;-)
> 1. Any compromise of the server would reveal years of messages for all
> users, not just any plain-text messages that were exchanged during the
> attack. (Push Archiving allows the client to (re)encrypt messages before
> storing them, so even a compromised server cannot decrypt them.)
Right, that is good.
> 2. Autoarchiving is not compatible with the evanescent keys used for
> secure end-to-end encryption - so you have to trust your server and your
> correspondant's server.
> Autoarchiving is certainly more practical than Push Archiving, and
> legislation makes it necessary in some cases. So in practice people will
> use it. But IMHO, for the reasons above, the JEP should require
> autoarchiving servers to also support Push Archiving (not difficult). In
> line with Jabber's "simple clients" philosophy, clients could choose not
> to implement push archiving.
I doubt that most will, but what do I know...
> Trejkaz wrote:
>> I would rather opt for doing it as file transfer between clients
> I think that the file format could be defined in JEP-0136, but any
> client-2-client synchronization process would be outside the scope of
Sure, the clients could use any defined method for that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards