[Standards-JIG] Thought about serverside messages archives

Ian Paterson ian.paterson at clientside.co.uk
Sat Apr 15 12:10:09 UTC 2006


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.

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.

Yes.

> expiration time of archive

As an optional Ad-Hoc command.


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?


> 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. [IMO we have a responsibility to care
about this - even Microsoft understands security is important now.]

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.)

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.


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
JEP-0136.

- Ian




More information about the Standards mailing list