[Standards] SIFT revisited

Brian Cully bcully at gmail.com
Sat Jun 6 01:54:44 UTC 2009

Sorry, on my phone so I can't do proper inline replies.

Maybe I'm missing something, but preserving presence on the server  
until a subsequent iq or message stanza leads to dos attacks via  
resource consumption. Is that not what you were advocating?


On Jun 5, 2009, at 19:29, Dave Cridland <dave at cridland.net> wrote:

> 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 benefits.
> 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.
> -- 
> 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