Dave Cridland wrote: >> I disagree. The spec says that the version ID is opaque. If the examples >> include only version IDs that are *not* opaque, developers will ignore >> the text and focus only on the examples. >> > I think he's right - it's impossible to order two hashes, so "real" > implementations - those capable of producing intermediate pushes - are > going to use some form of "ver" with strict ordering properties
Using pure roster hash introduces collisions that are not rare at all: Roster v10: [[email protected]] Roster v20: [[email protected], [email protected]] Roster v30: [[email protected]] Hash(Roster v10) == Hash(Roster v30) 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 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. -- WBRBW, Leonid Evdokimov
signature.asc
Description: OpenPGP digital signature
