[Standards-JIG] Message archiving

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Fri Apr 30 00:05:46 UTC 2004


Hi all,

I've written a rough JEP on message archiving:
  http://delta.affinix.com/specs/jep-archive.html

Comments welcome.

One concern raised on the council list is that the specification disregards 
JEP-13.  This issue needs to be discussed, and so I've started this thread 
here.

I recall making comments about server-side history when JEP-13 was still 
Experimental, since it sure looked like it could be useful for that.  
However, now that JEP-13 is Draft, and jep-archive isn't anything like what I 
was pondering a year ago, I don't think sharing or integration between these 
jeps are possible.

Both jeps have a way to request an item list.  For -13, the entire list is 
requested.  For -archive, this is probably never a good idea, and so extra 
parameters must be provided to filter the results.  My jep currently lets you 
specify a date range, but we probably want even more control here (like an 
x:data search facility).

Requesting messages is also a different matter.  With -13, individual messages 
are requested and sent to the user as actual message stanzas.  With -archive, 
entire collections of messages are sent to the user, and they are sent 
wrapped in an iq packet.  This wrapping allows jabber entities other than the 
server to relay archived messages with proper addressing.  For instance, it 
would be possible to have a purely client-side implementation of -archive, so 
you could sync your history between logged-in resources.  Considering that 
many public servers probably wouldn't touch -archive with a 10-foot pole, 
this is important.

Another major issue remaining is that item lists and message collections can 
easily be large.  This presents two problems:  1) sending a large stanza 
blocks all further communication over the XMPP channel, and 2) sending a 
large stanza might fail.  This means it might be worthwhile to split the 
transmission over a series of stanzas, maybe using a <more/> item in the iq 
packet to indicate that the client should perform subsequent requests to get 
remaining data, or perhaps using Inband-Bytestream to split a large stanza 
into sub-packets.  In either case, this is quite far from -13.

Note:  The text above was not planned.  I read JEP-13 just an hour ago, and 
this is what I came up with.  The reason JEP-13 was originally disregarded in 
jep-archive is because my spec was incomplete, not because of the reasons 
listed above.

-Justin



More information about the Standards mailing list