[Standards] Re: [jdev] XEP-0115: Entity Capabilities
kevin at kismith.co.uk
Tue Jul 3 15:40:27 UTC 2007
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
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.
More information about the Standards