[Standards] UPDATED: XEP-0237 (Roster Versioning)

Matthew Wild mwild1 at gmail.com
Wed May 13 14:23:17 UTC 2009

2009/5/13 Jiří Zárevúcký <zarevucky.jiri at gmail.com>:
> 2009/5/13 Waqas Hussain <waqas20 at gmail.com>:
>> Programmers for whom ver='qAxdnWNcA+lYf7CoN5wpBsvVVno=' would be
>> entirely impossible... I think those exact programmers are the reason
>> for not using ver='1' :-)
> If it is a hash of a complete roster (as Peter has told) then the
> server would have to decode this hash, figure out exactly what version
> that was, create a difference, figure out the version for every
> change, and send every change with the appropriate full roster
> checksum again. I'm not that much into cryptography, and it depends on
> the kind of hashing used, but if that possible, someone implementing
> this would at least be completely out of his/her mind.

There is no "decoding" a hash. It is used to give each version of the
roster an "automatic" version number if you like. In almost all
respects it is otherwise the same as incremental numeric versions.

>> The XEP is short and clear. The 'ver' attribute is an opaque string
>> for clients, and client programmers shouldn't care what it's value is.
>> I don't see a problem here.
> XEP is short and clear and nobody will ever have any problem reading
> it. Examples are way more confusing because of some theoretical idiot
> that's implementing example and not the XEP. Do we really want to make
> obscure examples because of people that are probably incapable of
> implementing it at all?

Obscure? And so what if they implement the examples and not the text
of the XEP? The examples are valid too you know :)

I for one don't think that this particular issue warrants further
discussion. The XEP is absolutely fine as-is.


More information about the Standards mailing list