[Standards] Proposed XMPP Extension: Roster Versioning

Peter Saint-Andre stpeter at stpeter.im
Wed Mar 5 00:37:34 UTC 2008

Dave Cridland wrote:
> 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. :-)

Yeah yeah yeah, copy and paste error, always working too fast...

> "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.

Sure, that seems reasonable.

> 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.

Ah, good point.

> 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.

Right, I left out the groups because I'm lazy. I'll add a few in.

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

I defined a boolean 'diff' attribute for this purpose.

> 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.

Is that really necessary for the intended purpose (optimization of
roster gets)? Or is it just a cool feature that piggybacks on the
optimization use case?


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/20080304/084fca2c/attachment.bin>

More information about the Standards mailing list