[Standards] Proposed XMPP Extension: Roster Versioning

Dave Cridland 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  
> their
> >> > 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  
> XEP-0060
> > which changes PubSub pushes from being <message/> to <iq/>, in  
> (for
> > example) section
> >
> > Or, alternately, could someone explain to me why the use of  
> <message/>
> > stanzas for the 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  
> knowing
> the full JID (and stock pubsub services do not know that).
Gosh - you mean you chose <message/> because of its network  
properties? ;-)

> 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  
> problem
> 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  
cost power.

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.

> or
> (2) sending roster pushes via <message/> is a pretty optimization  
> that
> is more elegant than what we developed in 1999, but it fundamentally
> unnecessary
> I think (2) obtains. Therefore I think it's just fine to keep IQs  
> for
> 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
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list