[Standards] SIFT revisited

Dave Cridland dave at cridland.net
Fri Jun 5 23:29:50 UTC 2009

On Fri Jun  5 23:57:06 2009, Peter Saint-Andre wrote:
> Fabio Forno has found some good results with SIFT on a mobile phone:
> http://blog.bluendo.com/ff/xmpp-and-compression-a-little-experiment

Hmmm - I had a long chat with Forno the other evening, and I've been  
meaning to write it up in a more formal way for us all to share...

The general idea is that instead of SIFT at all, we have a single  
command which simply says "Don't send my presence *until* you've  
something else to send me." - or turns off that state. Nothing gets  
dropped, just delayed, maybe by a maximum time.

So <presence/> gets buffered until either a <message/>, or an <iq/>,  
needs sending. The client can flush the pending presence in a number  
of ways, the most obvious one being simple using a XEP-0199 ping -  
the response being quite sufficient to flush the presence down.

The user experience looks roughly as if presence is sometimes out of  
date for a short while, but if a message arrives, it would "push  
down" any delayed presence updates, so it wouldn't be often.

This is, I'd note, a pretty simple protocol to implement, and the  
interesting thing about Fabio's experiment is that it shows it'd give  

If we want to get complicated, we can point out that if we're  
buffering presence anyway, we might collapse presence stanzas that  
are overtaken by events - so if you go away, then xa, then offline,  
the server *might* drop the away/xa changes, and just give the phone  
a single offline.

Now, the reason I don't think the rest of SIFT helps is that I'm not  
convinced that much "unsolicited" <iq/> traffic actually happens,  
because well-behaved actors, at least, will check the disco#info and  
only send <iq/> stanzas supported by the remote end. There are  
exceptions, such as version queries, vcards from MUC (please, folks,  
fix those), and pings - the latter, of course, rather relies on  
getting through.

Actually *dropping* data just strikes me as poor - I think we can do  
much better than that.

FWIW, I *do* think that people want to have the concept of a "session  
roster" vs "full roster", but I think that's a different problem to  
solve. (And one that's quite easy, too, but harder to implement).

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list