On Mon, Feb 1, 2010 at 8:56 PM, Ben Schumacher <Ben.Schumacher at webex.com> wrote: > On 01/30/2010 03:29 PM, Jonas Lindberg wrote: >> While I agree this would simplify the protocol a little, I am not >> convinced it is a change worth making. >> >> First of all, not responding to probe when unavailable is a pretty >> good optimization. A large part of Xmpp traffic is presence. This >> change would further significantly increase the presence traffic, >> making scaling more challenging and adding load to c2s and s2s >> connections. For example, a cell phone xmpp client may be better off >> not getting potentially thousands of presence unavailable stanzas for >> offline friends when connecting over gprs. >> >> I'm also not convinced this change make it significantly easier to >> implement xmpp clients/servers. Especially if we are going to >> recommend that clients and servers SHOULD cope with no response for >> legacy reasons. >> > > Jonas- > > I agree with your points -- it would likely result in extra traffic. > That being said, I much prefer this to the ambiguity (and potential > presence leak) of the prior language. As it happens, servers and clients > will *always* have to cope with no response as this is a network'd > service and packets can get lost, etc, so I'm not sure the language > should be "SHOULD" re: legacy services, but rather maybe a note that > indicates that you may not get a response. > > Ben > While one can argue it's a little prettier, I don't think it's very practical. Making this change at scale requires very significant work and comes at a significant cost in traffic increase (consider user with >1000 mostly offline friends). It will also result in worse user experience for users with large rosters on low bandwidth connections, like the common scenario of a cell phone. Clients will need to deal with presence leaks as long as delivery isn't guaranteed.. How about just adding an probe answer-required extension?
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.