[Standards] Re: [jdev] XEP-0115: Entity Capabilities

Kevin Smith 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  
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.


More information about the Standards mailing list