[Standards] UPDATED: XEP-0237 (Roster Versioning)

Peter Saint-Andre stpeter at stpeter.im
Fri May 15 04:37:05 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/14/09 10:09 PM, Leonid Evdokimov wrote:
> I have a bit more misunderstanding, uncertainty and doubt:
> 
> See example 4:
> 
> C:<iq from='romeo at montague.lit/home' to='romeo at montague.lit' type='get'>
>     <query xmlns='jabber:iq:roster' ver='ver14'/>
>   </iq>
> ...
> S:<iq from='romeo at montague.lit' to='romeo at montague.lit/home' type='set'>
>     <query xmlns='jabber:iq:roster' ver='ver42'>...</query>
>   </iq>
>   </stream:stream>
> 
> [ reconnection ]
> 
> C:<iq from='romeo at montague.lit/home' to='romeo at montague.lit' type='get'>
>     <query xmlns='jabber:iq:roster' ver='ver34'/>
>   </iq>                             <!-- ^^^^^ -->
> 
> As far as I see, the client should send "ver42", not "ver34". Server
> replies confirm this assumption.

Typo (bad copy and paste).

> See section 5.4 Sending Pushes:
> 
> For instance, if a series of roster modifications result in a roster
> item that does not differ from the version cached by the client (e.g., a
> modification to the item's 'name' attribute and then a modification back
> to the original value), then a server that implements the "complete
> roster hashes" approach would consider the item to have __NOT__ been
> modified for purposes of roster versioning and therefore would __NOT__
> push the item to the client in an interim roster push; however, a server
> that implements the "strictly increasing sequence numbers" approach
> would send a roster push in this situtation.
> 
> Seems, the text with "__NOT__"`s makes more sense than without them. Am
> I completely wrong?

Fixed.

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0237.xml?%40diffMode=u&%40diffWrap=s&r1=3141&r2=3142&u=3&ignore=&k=

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoM8XEACgkQNL8k5A2w/vyLQACfXOBz08RGdoOKxEEvxqXcAEGH
wpwAnRv1wYXGqGotZSfJkoel7mDUPdnY
=sNxr
-----END PGP SIGNATURE-----



More information about the Standards mailing list