-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/28/09 5:51 AM, Dave Cridland wrote: > On Tue Apr 28 12:04:54 2009, Leonid Evdokimov wrote: >> Roster v10: [...@example.com] >> Roster v20: [...@example.com, 2...@example.org] >> Roster v30: [...@example.com] >> >> Hash(Roster v10) == Hash(Roster v30) >> >> > And this is okay, since a client that says "I have Hash(Roster v10)" has > the correct roster even if it's actually "Hash(Roster v30)" that the > server has.
Correct. The client has the same roster that the server has, so the client now knows that it is up to date. Which is the whole point. >> I think, this collision contradicts with the letter of the XEP: >> >> | The server MUST ensure that each roster modification will result in >> | a different version and that the version associated with a given >> | roster modification will be different from version associated with any >> | previous roster modification for this session >> >> > Yes... That text now doesn't apply to all implementations -- it was tied to the strictly-increasing sequence number approach. >> So, `Hash(Roster)` recommendation in `Implementation Guidelines` should >> be replaced with something like `Hash(Nonce || Roster)` to follow the >> letter of the XEP. And I see no good reason to use `Hash` if `Nonce` is >> used. > > No, I think the text you quote above is wrong. > > Once you allow for Hash(Roster), it's possible to basically drop the > requirement for unique "ver" for each roster modification, within a > session or otherwise. Agreed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn3U2kACgkQNL8k5A2w/vw28gCg+dOFYeWzzvvLHqtEp5Svbr95 TFwAn1oAcPQfJFlWAbjO/gqQ3yGmzYQA =dRQr -----END PGP SIGNATURE-----
