On 4 Jul 2007, at 00:19, Mridul wrote:
Considering an ext of "my_ext 1233ab" and "#hash1 #hash2" exhibited by two clients - how would the reciever know what is hashed as per 'new' idea and what is 'old' ver/ext ? In first case, it wont hash properly to what is exhibited by disco - which might make the 'new' client think it is hitting a problem client instead of a old client.
I was thinking about this a couple of minutes ago, and actually I think that that's fine. Either because it's a broken caps, or an old caps, the client will need to go discoing. This means that new clients will end up discoing old clients repeatedly until they're upgraded (or until they find a hash which matches a featureset, if it wasn't old, but broken) but that's the argument people have been making, isn't it? (That it's not safe to do anything else with current caps).
I think in practise people would carry on treating new caps like old caps, and cache it even if it doesn't match, until some arbitrary point in the future when the cacheing for mismatching hashes is turned off (in say a year when everyone deploys newcaps, or if caps poisoning becomes a big problem).
As an aside: caps poisoning does happen; we've been seeing it in the wild with Psi already. Some (I guess old and obsolete) transports simply mirror the presence stanza back to the client. In this case, Psi is told that the transport is Psi (by its own mirrored presence). We don't have Psi's caps cache yet (now we ship with own-caps abuse like this resolved, but it happened for a while) so we disco the transport, and bang, Psi has no features.
/K
