[Standards-JIG] UPDATED: JEP-0136 (Message Archiving)
ian.paterson at clientside.co.uk
Sun Sep 10 12:04:44 UTC 2006
Olivier Goffart wrote:
> Yes, but what if i use an old client which doesn't support the
> feature at all ? Messages are then not logged -> data loss
Yes, but the situation will be vastly improved from today's, where tiny
clients either don't or can't store data locally (e.g. Web/mobile
clients). Tiny clients have the most to gain from this protocol, and
sending <auto/> is trivial for any client... if your client doesn't
implement <auto/> then it really should. So use a different client
(there are a lot out there).
Your server can be expected to take much longer than your client to
IMHO there is no serious or long-term issue here, so privacy concerns
should take precedent. [I remember these concerns aren't particularly
important for you, but they are crucial for a lot of (oppressed) people
who we have to respect.]
See below for another significant argument for auto-archiving always
defaulting to 'off'.
Note that the protocol says "Automatic archiving SHOULD default to
disabled" (not MUST). The reason for SHOULD is that the policy of an
organization may require an administrator to change a server's default
setting so that it logs all messages (in which case clients should not
be able to disable auto-archiving).
So we probably need an extra protective clause in JEP-0155 (and
JEP-0136) to say that a client MUST NOT agree to logging='false' unless
it has confirmed that its server will allow it to switch off
auto-archiving. JEP-0155 is still "Experimental" so we could even change
the name of the 'logging' field to 'otr', so clients can be sure they
are not dealing with a legacy implementation. What do you think Peter?
>> [...] 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 to analyze JEP-0155 messages?
No. Perhaps something in the protocol has not been made clear to you? If
the clients agree there will be no logging of any kind using the
JEP-0155 'logging' field, then it is the responsability of each client
to switch off *its own* auto-archiving and/or any of the other archiving
methods they might be using. If you could tell me which part(s) of the
JEP may have mislead you then I'll try to make things more clear for
> And if the other client doesn't support OTR (but his server does) ?
If the other client doesn't support OTR then it is probably archiving
locally in a completely different (proprietary) way. So you have no OTR.
1) You use JEP-0155 to get the other client to agree to switch off its
non-standard archiving (all archiving), and
2) Auto-archiving defaults to 'off' on the other client's server.
> Maybe could work if a <otr/> tag is added in
> messages so the server knows it is otr.
IMHO, this server analysis of every stanza is undesirable, and not at
all helpful. (Since contacts that don't understand JEP-0136 will
probably be archiving in some other way, in which case only JEP-0155 can
>> Since the private keys are long-lived, they
>> could be transported via USB-key.
> Not really user friendly.
> Or is encryption reserved to geek ?
Yes, I agree, this is not a good solution. I only mentioned it because
it should be more secure than the other solution:
>> 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)
Could be, although we would still need a JEP to standardise the content
of the <query/> element. Also jabber:iq:private is probably going to be
depricated in favour of PEP (JEP-0163) so new protocols should avoid
This method becomes more secure if it is only used to transfer a private
key in-band. i.e. ClientA encrypts the key with a password supplied by
the user and stores it on the server, the next time ClientB comes online
it retrieves the key and then immediately deletes the copy on the
server. This way the period of vulnerability is significantly reduced.
Unlike the USB-key transfer method, this process could be made
transparent to users.
> 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 with
> The possible solution is to let the server aware of the public key, so it can
> generate secret session keys himself.
Very good point. I'll make that change to the protocol.
Thanks again for all your input (even the bits I disagreed with). :-)
More information about the Standards