On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp <[email protected]> wrote: > > Am 23.04.2009 um 20:13 schrieb Peter Saint-Andre: >> >> His argument was that the server might make the 'ver' attribute >> something like a hash of the roster, which would be opaque to the client >> but meaningful to the server so that it could figure out if it would >> return an empty IQ-result or the full roster (leaving aside the roster >> push for now). That seems like a perfectly acceptable approach to me as >> a minimal implementation, so I'm wondering if we want to say that the >> 'ver' value needs to be opaque to the user but meaningful to the server, >> and that one possible implementation is a strictly increasing sequence >> number. > > If the ver attribute is some kind of a hash of the roster, a additional > feature could be added, to inform the client which method was used to > generate the hash. So the client can check the current roster. This way > corrupted rosters can be detected and no user interaction is required. >
I'd rather keep it opaque to the client. Rosters shouldn't get corrupted during transfer, that's what TCP is for :) If we /did/ want any such corruption detection then it belongs in another XEP in my opinion, rosters aren't the only thing you want to check. The hashing algorithm of each server would be different anyway, and I don't see that clients would want to support each and every one individually. Matthew.
