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

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


2009/5/13 Waqas Hussain <waqas20 at gmail.com>:
> 2009/5/13 Jiří Zárevúcký <zarevucky.jiri at gmail.com>:
>> 2009/5/12 Peter Saint-Andre <stpeter at stpeter.im>:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 5/9/09 12:52 PM, Jiří Zárevúcký wrote:
>>>> I have read the text again after a while and the following text got my
>>>> attention:
>>>>
>>>>> If a series of roster modifications result in a roster item that does not differ from the
>>>>> version cached by the client (e.g., a modification to the item's 'name' attribute and
>>>>> then a modification back to the original value), the server SHOULD NOT consider the
>>>>> item to have been modified for purposes of roster versioning and therefore SHOULD NOT
>>>>> push the item to the client in an interim roster push.
>>>>
>>>> That part is not very useful, since servers will hardly keep track of
>>>> every previous roster version. I don't even want to think about the
>>>> CPU overhead that will kill the cluster every 30 minutes (that's a
>>>> hyperbole of course). > The simplest "full featured" implementation
>>>> consists of integer version numbers and "mver" field for every roster
>>>> item.
>>>
>>> This is purely an implementation decision and I think we need to remove
>>> the conformance language here (i.e., no MUST, SHOULD, SHOULD NOT, MAY).
>>> If the server chooses the "hash complete roster" approach then it won't
>>> send the push. If the server chooses the "integer version numbers"
>>> approach then it will send the push. End of story.
>>>
>>>> Server will then send all the items whose mver is greater than
>>>> client's ver. Any throughout checking would hardly ever have any
>>>> benefit.
>>>
>>> What is mver?
>>>
>>
>> The same relation as with time and mtime on files. It's the version of
>> last change.
>>
>>>> -----
>>>>
>>>> About the opaque vs. integer examples dilemma. I think if someone
>>>> really doesn't read the text, his implementation won't work at all
>>>> anyway. The examples are kinda confusing this way. If you really want
>>>> some opaque strings there, use "AAAAA", "BBBBB", "CCCCC" or something
>>>> like that, so the sequentiality is obvious.
>>>
>>> A sequence number is not really opaque, is it? The examples currently
>>> use the "hash complete roster" approach. I would prefer to err on the
>>> side of not misleading clients about sequentiality ("the examples have
>>> AAAAA and BBBBB so I suppose the next 'ver' will be CCCCC" and then the
>>> client breaks when that's not the case).
>>>
>>> Peter
>>>
>>
>> Ok, so in order to not confuse stupid programmers with a specific
>> implementation, we will confuse them with one entirely impossible. I
>> get your thinking *THUMBS UP*
>>
>
> 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.

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



More information about the Standards mailing list