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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
