[Standards] Proposed XMPP Extension: Roster Versioning

[Pedro Melo]

Hi,

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

+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?

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!