[Standards] Proposed XMPP Extension: Roster Versioning

Peter Saint-Andre stpeter at stpeter.im
Thu Mar 6 04:36:18 UTC 2008

juha.p.hartikainen at nokia.com wrote:
> Hi!
> I readed the latest version 0.0.3 and I'm little bit confused of
> statement (or I have 
> missed something):
> --- clip ---
> The "roster diff" can be understood as follows:
>    1. Imagine that the client had an active presence session for the
> entire time between its cached roster version (in this case, 305) and
> the new roster version (317).
>    2. During that time, the client would have received roster pushes
> related to roster versions 306, 307, 308, 309, 310, 311, 312, 313, 314,
> 315, 316, and 317.
>    3. However, some of those roster pushes might have contained
> intermediate updates to the same roster item (e.g., changes in the
> subscription state for bill at shakespeare.lit from "none" to "to" and from
> "to" to "both").
>    4. The roster result would not include all of the intermediate steps,
> only the final result of all changes applied while the client was in
> fact offline.
> --- clip ---
> Q: How many roster version have to server remember? In the xep 0.0.3
> there is clear spec for client site implementation, 
> but server site is missing "server site requirements". If I keep
> changing the roster add, remove few times 
> ("on/off relationship") --> how many roster versions have to be server
> must remember backwads 1...n? 

I suppose that's up to the implementation. But if the server doesn't
remember back to the version cached by the client then we need to
specify the server's behavior (probably it would return the latest
version of the entire roster, just as it does today).


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080305/d788a4d0/attachment.bin>

More information about the Standards mailing list