[Standards-JIG] NEW: Message Archiving

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Sun Jun 6 09:16:54 UTC 2004

On Saturday 05 June 2004 10:41 pm, David Yitzchak Cohen wrote:
> On Sun, Jun 06, 2004 at 12:00:31AM EDT, Justin Karneges wrote:
> > and for offline messages it is x:delay which is
> > shown to the user.
> There, sadly, you have no way of preventing the server from having
> fun with dinosaur era messages without control of your own server at
> a minimum.

Your server can do far worse things, like masquerade as any other user on 
Jabber.  I don't think it is worth recording two timestamps in a feeble 
attempt to compensate.

> > On a related note,
> > should the client be able to specify a timestamp for a message
> > collection?
> Shouldn't the timestamp range for a message collection be calculated by
> the server based on its components?  Oh, you mean, to have a timestamp on
> "when the collection was collected," or something like that ... um ... I
> don't have need for such an extension, but I wouldn't call it useless.

Well, if you receive an x:delay message, and upon login you receive it and 
archive it, what would be the date of the collection?  I think I asked this 
question because it might provide some sort of compromise with your x:delay 
concern, as you'd wind up with two start times then, one essentially being 
the time of receipt.

> > Regarding to/from, this is determined by the presence of a "to" or "from"
> > attribute in the message (the JEP forbids logging both, although it could
> > be better spelled out).
> In other words, a user can't log messages from third-party conversations
> (say, another of his JIDs) without losing some info.  ("Your pick:
> either you lose the sender, or the recipient; but you can't have both!")

This is an interesting point.  Currently the protocol has a first-person angle 
to it.  Maybe a collection shouldn't have just a 'jid', but instead an 
'a' (the logger) and 'b' (the peer), thus allowing you to archive any 
conversation, not just your own, with no real distinction between who is 
closer to the reader. :)

And actually, logging both the 'to' and 'from' in a message stanza doesn't 
need to be forbidden (and as I reread the JEP, I see that it is not), just 
that at least one needs to be present to derive the proper sender.

A related issue is how to deal with JID resources.  Logging both the full 
to/from JIDs in the message stanza would allow us to retain this information, 
however it is also completely redundant, since the resources should never 
change in a normal conversation.  The only gray area is the start of a chat, 
when you have sent the first message and have not received a reply yet.  
Maybe once the resource is determined, the 'to' (or 'b', heh) of the 
_collection_ should be updated to reflect it.  If you never get a reply, then 
'b' will remain the bare JID.

The one exception to all of this is groupchat, where the resource will 
constantly differ, and so in that case we wouldn't want to change the 
collection 'b' value, but we do want to record the nickname in the stanza.

Maybe something like this would be good:

<message xmlns='jabber:client' archive:origin='a'>
  <body>How are you?</body>

<message xmlns='jabber:client' archive:origin='b'>
  <body>Just fine, thanks.</body>

And for groupchats:

<message xmlns='jabber:client' archive:nick='ahkitj'>
  <body>/me waves</body>

Notice that there would then be no distinction between 'a' and 'b' in a 
groupchat.  The person doing the actual logging is no different from any 
other participant, aside from that his jid would be the 'a' in the collection 
(maybe this could be an optional field then).


More information about the Standards mailing list