[Standards] Proposed XMPP Extension: Roster Versioning
dave at cridland.net
Mon Mar 17 22:53:59 UTC 2008
On Mon Mar 17 16:31:06 2008, Peter Saint-Andre wrote:
> Dave Cridland wrote:
> > On Mon Mar 17 15:22:28 2008, Peter Saint-Andre wrote:
> >> Pedro Melo wrote:
> >> > Lets not abuse the meaning of <message> just because we like
> >> > network properties, like we abused <presence> in the past
> because it
> >> > broadcasts well.
> >> +1.
> > Absolutely. So I'm looking forward to seeing the update to
> > which changes PubSub pushes from being <message/> to <iq/>, in
> > example) section 184.108.40.206.
> > Or, alternately, could someone explain to me why the use of
> > stanzas for the 220.127.116.11 case is not "abuse", whereas would be.
> Looks to
> > me like they're the same use-case.
> Very funny. :P
> We use messages there in part because using IQs would require
> the full JID (and stock pubsub services do not know that).
Gosh - you mean you chose <message/> because of its network
> But that's neither here nor there. The question is whether:
> (1) acking an occasional roster push from the server to the client
> (where BTW the server *does* know your full JID) is a serious
> that we need to solve because it wastes large amounts of bandwidth
It's not the bandwidth, it's the additional transmission I'm more
concerned with. For every <iq/> stanza, there's an addition TCP data
packet, and therefore there'll be a further ACK - both of which will
The alternative is that we quietly explain to people that they
needn't bother replying to the <iq/> push, which I really don't like.
I'm pretty sure that the mobile developers won't want to reply to
every roster push, anyway.
> (2) sending roster pushes via <message/> is a pretty optimization
> is more elegant than what we developed in 1999, but it fundamentally
> I think (2) obtains. Therefore I think it's just fine to keep IQs
> roster pushes. If it ain't broke, don't fix it.
Nothing here is necessary; the question is whether we can, and
should, do it.
Remember, rosters are not broken right now - they work just fine. So,
if we're going to change things, we may as well consider how much we
can change things, rather than how little.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards