[Standards] Proposed XMPP Extension: Roster Versioning

Dave Cridland dave at cridland.net
Tue Mar 4 22:27:29 UTC 2008

On Tue Mar  4 21:54:31 2008, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Roster Versioning
> Abstract: This specification proposes a modification to the XMPP  
> roster management protocol to support versioning of rosters for  
> more efficient downloading of the rost er information.
> URL: http://www.xmpp.org/extensions/inbox/roster-versioning.html

"Note: This document is provided for discussion purposes in order to  
clarify the usage of SASL ANONYMOUS in XMPP systems. It is not meant  
to supersede the text in RFC 3920, RFC 4422, or RFC 4505. However,  
the recommendations in this document may be folded into rfc3920bis."

Good to know that's cleared up, anyway. :-)

"The value of the 'version' attribute MUST start at zero (0) and MUST  
be incremented by one (1) for each change to the roster."

I would personally prefer that this read:

"The value of the 'version' attribute is an integer value which is  
increased with any change to the roster, whether or not the client  
supports this extension. In particular, the 'version' attribute  
contained in roster pushes (see Section 2.5) MUST be unique."

(Insert RFC 2119 language to suit).

My reasoning is:

a) Servers might need to increase it by more than 1 for some changes,  
if they're not performed atomically.

b) Servers may need to increase it for changes which are not  
user-visible, such as the from-pending state.

c) We might need to change it in the future for other purposes.

Section 2.2:

Include some text saying that clients can set version to 0 if they  
have no roster cached with a version - otherwise there's no bootstrap.

Sections 2.4/2.5 contain no closing </query>, and don't show groups,  
etc. Both need to specify that the complete roster item is used.

Section 2.4 needs to include a method for servers to indicate whether  
this is an update, or a complete replacement.

Finally, I'd include an assertion for roster sets - so that a client  
can perform actions such as a "set if not changed since". Dead easy  
for servers, I think.

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