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
implementations.
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
more
people implement the new protocol the fewer IQs we get.
Of course this can be avoided by maintaining the existing caps
protocol...
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
there
(cf. SCRAM).
The problem isn't the individual implementations; it's the deployed
state.
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.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
