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

Peter Saint-Andre stpeter at jabber.org
Tue Jul 3 15:53:25 UTC 2007

Kevin Smith wrote:
> 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).

So you're saying that newcaps packets would look like this:

<presence from='bard at shakespeare.lit/globe'>
  <c xmlns='http://jabber.org/protocol/caps'


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

Erk. That's bad.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070703/c2c5c7d3/attachment.bin>

More information about the Standards mailing list