[Standards] Proposed XMPP Extension: Roster Versioning
melo at simplicidade.org
Tue Mar 4 23:48:53 UTC 2008
On Mar 4, 2008, at 10:27 PM, 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
> "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.\
+1. I can't see any reason for the spec to require more than a
increasing version number.
> 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.
Or omit the version maybe?
> 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
+1 for groups.
> Section 2.4 needs to include a method for servers to indicate
> whether this is an update, or a complete replacement.
Why? A complete replacement is just a full set of updates. The final
XML would be equivalent. From the client perspective, he would
replace all the cached local entries.
> 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.
I don't follow what this is. Can you elaborate with a use case?
XMPP ID: melo at simplicidade.org
More information about the Standards