[Standards] Addressing Security Concerns in XEP-0115 Entity Capabilities
dave at cridland.net
Fri Sep 16 21:26:34 UTC 2011
On Fri Sep 16 21:15:43 2011, Florian Zeitz wrote:
> Hence a new protocol dropping the old one at the same will:
> a) Make old implementations send IQ queries to the new
> Number of IQs increases with the number of implementers of the new
> protocol for some time, but at a certain point that turns and the
> people implement the new protocol the fewer IQs we get.
Of course this can be avoided by maintaining the existing caps
> b) Gives us a clean cut without ugly hacks (which may or may not
> even work)
> c) Keeps presence about the same size
... which does increase the size of stanzas, but I don't think
that'll be a concern.
> d) Breaks e.g. PEP on servers, however I'm under the impression that
> servers are easiest to get updated since there is some competition
> (cf. SCRAM).
The problem isn't the individual implementations; it's the deployed
We know that at least some XEP-0115 consumers don't bother examining
them if there isn't a hash-based XEP-0115 caps.
I think it's worth stepping back and re-examining what we need from
caps, and what we could get, as a first step.
To give an example, we could have receivers of unknown caps ask their
localserver to expand them - this would radically reduce traffic on
the network as a whole, and their local server will probably need to
know the features anyway for PEP, etc.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards