[Standards] Proposed XMPP Extension: Roster Versioning

Daniel Henninger daniel.henninger at jivesoftware.com
Thu Mar 6 23:17:34 UTC 2008

Just an additional note, OSCAR (AIM/ICQ) does this too.  Basically all you really do is see what version of your SSI is stored on the server, see if that's the same number as what you have recorded in your client, and if they differ, clearly something has changed and you need to pull the update from the server.  It is sequential, but it doesn't matter that it's sequential.  (or at least I've never seen an instance where it matters)  I might be remembering this wrong too.. it might be that you send the version YOU know about, and OSCAR either sends you "you're good" or it sends you your roster.  One of those.  Either way, doesn't matter what the "key" is really.  =)  It's just conceptually easier to think about it in terms of version numbers.


----- "Dave Cridland" <dave at cridland.net> wrote:
> On Thu Mar  6 22:23:51 2008, Pedro Melo wrote:
> > Others might counter-propose something meaningful but some are   
> > proposing something opaque, without meaning for the client. And  
> > that  is the best way for clients not to mess up.
> Okay, I call. :-)
> How *can* clients mess this up by knowing they can compare two
> values?
> It's never, to my knowledge, been a problem in ACAP or IMAP, both of 
> which use something similar. It's been quite handy in IMAP CONDSTORE, 
> in fact.
> The only particularly curious thing about integers is that it's  
> possible to note that, given two values, there's a maximum number of 
> changes that have happened between them. (But a fixed minimum of  
> zero, since the server's allowed to skip values). But even if a  
> client decides that the sequence values always change by one, and  
> only for a visible change, I can't see any possibility for a protocol 
> error. I'm not even sure what you'd do with that erroneous  
> information, but maybe I'm too used to dealing with these things.
> So, please enlighten me - what is it that I'm missing?
> > Agreed. Hence a recommendation on implementation notes to use a   
> > counter with those properties.
> If clients did "mess it up", probably by testing against servers  
> using an integer, relying on it somehow, then finding servers with an 
> opaque string in the field, how much worse will the problem be? (See 
> Curtis's email for a very accurate account of how many  
> implementations get developed).
> Either make it "really" opaque, if you have to, or else make it  
> clearly defined. So if you're going to remove the "integer" property, 
> then you'd best make it such that clients *cannot* compare it at all. 
> (Good luck with specifying that).
> FWIW, I've said before that it's perfectly possible to map strictly  
> increasing modified timestamps to a strictly increasing integer. I'm 
> not dictating server internals - you can generate a strictly  
> increasing sequence value however you like, as long as you can map it 
> to an integer.
> Dave.
> -- 
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
>   - 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