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.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
