[Standards] Proposed XMPP Extension: Roster Versioning

juha.p.hartikainen at nokia.com juha.p.hartikainen at nokia.com
Wed Mar 5 21:40:28 UTC 2008


Sorry missed to say that user might use several client, which caches the


>-----Original Message-----
>From: Hartikainen Juha.P (Nokia-S&S/Oulu) 
>Sent: 05 March, 2008 23:37
>To: 'XMPP Extension Discussion List'
>Subject: RE: [Standards] Proposed XMPP Extension: Roster Versioning
>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? 
>>-----Original Message-----
>>From: standards-bounces at xmpp.org
>>[mailto:standards-bounces at xmpp.org] On Behalf Of ext Alexander Gnauck
>>Sent: 05 March, 2008 22:45
>>To: standards at xmpp.org
>>Subject: Re: [Standards] Proposed XMPP Extension: Roster Versioning
>>Peter Saint-Andre schrieb:
>>> Here is revised text:
>>>    The value of the 'version' attribute SHOULD be a non-negative
>>>    integer representing a strictly increasing sequence number that
>>>    is increased with any change to the roster (whether or not the
>>>    client supports this extension) but MAY be a unique 
>identifer that
>>>    is opaque to the client but understood by the server. In 
>any case,
>>>    the 'version' attribute contained in roster pushes MUST 
>be unique.
>>great, +1
>>> Can we stop painting this bike shed and move on? :)

More information about the Standards mailing list