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

Florian Zeitz florian.zeitz at gmx.de
Wed May 13 23:40:14 UTC 2009

Hash: SHA1

Dave Cridland wrote:
> Yes it is, and it's also a terrible idea, since the server would then
> have an ever increasing number of versions, many of which would never be
> requested by the client, and likely none of which would be needed in
> entirety.
As I found this a rather harsh response I reread the XEP very thoroughly
(I suspect my last read was also a few revisions back) and I have to say
I'm pretty baffled.
(In my defence though the idea I had in mind was to only keep rosters
for a certain amount of time, or only a limited number, which I deemed
out of scope for the pseudocode)

I agree with Jiří Zárevúcký and Dave Cridland by now.
Most examples should have numbers. Example 3 because it makes it easier
to read. And Section 3 Examples, because 5.3 says so.

I'm also not really sure why anyone might ever want to use hashes. The
only upside is that in the all or nothing use-case (5.2) you don't have
to save any version, because you can compute it. But a) it is still more
or less recommended to save the hash for performance gain b) saving an
additional stricty increasing integer would work as well and be smaller
than a hash.
I unfortunately missed out on the discussion about making ver opaque,
but the result doesn't seem plausible to me right now...
I guess it is not a bad idea to define ver as opaque, but recommending
hashes, or anything other than integers just doesn't seem worthwhile...
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Standards mailing list