[Standards-JIG] UPDATED: JEP-0136 (Message Archiving)

Olivier Goffart ogoffart at kde.org
Sun Sep 10 08:01:40 UTC 2006


Le dimanche 10 septembre 2006 05:13, Ian Paterson a écrit :
[...]
> Anyway, simple client isn't really an issue here, because it is
> absolutely trivial for clients to switch on auto-archiving (just send
> <auto/>).

Yes, but what if i use an old client which doesn't support the feature at 
all ?
Message are then not logged -> data loss 

> If the user's client doesn't know how to switch auto-archiving on, then
> it certainly doesn't know how to retrieve the messages!

I may just use some web client or tiny client when I'm out of my home, and a 
smart client when I'm at home

> [...] You can't achieve OTR
> without JEP-0155 (or something else that does the same thing). Even if
> you implement OTR on the server, you've still got to ask your contact
> not to log messages in any of the numerous other ways that are possible.
> So you always need JEP-0155. So the question becomes: "What is the point
> in having server OTR if you've already got JEP-0155?" IMHO it just adds
> unnecessary complexity to both client and server.

So the server is supposed the analyze JEP-0155 messages ?  ok
And if the other client doesn't support OTR (but his server does) ?
Maybe could work if a <otr/> tag is added in messages so the server know it is 
otr.

> With manual archiving the idea is you don't trust your server (the
> messages hopefully arrived through an end-2-end encrypted session). So
> the client should perform both encryption and decryption.

OK

[...]
> >  - Else, how are the secrets keys shared between clients ?
>
> That is beyond the scope of JEP-0136. But perhaps we could add a note?
>
> Since the private keys are long-lived, they could be transported via
> USB-key. 

Not really user friendly.
Or is encryption reserved to geek ?


> Alternatively, they could be password encrypted and then stored 
> on the server using a to-be-defined standard protocol (on my list of
> protocols to write in 2007).

jabber:iq:private (JEP-0049)



> With auto-archiving things aren't so clear. [...]

The problem i see in the current implementation is that each client must have 
the private key in order to encrypt. or to enable automatic archiving wioth 
encryption

The possible solution is to let the server aware of the public key, so it can 
generate secret session keys himself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060910/93581738/attachment.sig>


More information about the Standards mailing list