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

Jiří Zárevúcký zarevucky.jiri at gmail.com
Wed May 13 15:13:34 UTC 2009

2009/5/13 Matthew Wild <mwild1 at gmail.com>:
> 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 :)

But that's exactly what those examples try to prevent in a very
questionable way, isn't it?

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

Ok, I give up. But let me explain it's not so much about the examples
being worse to read and understand (which they are). It's about taking
some ethereal idiot programmers into account when designing specs.
Next time we will binary encode them so someone doesn't try a human
language parser on the protocol. :)

More information about the Standards mailing list