When the world is fnaly but slowly moving toward one standard, it is stupid that Google should go against that.

@Ernest, @Janne, and others: I have nothing against a binary encoding in principal as long as it is a one-to-one transform to and from the verbose XML, and is still able to handle new namespaces. If a binary encoding is flexible enough to handle that, then I don't have a problem with it—as long as the standard is open. For example, one such binary encoding happens to be a zlib-compressed XML stream. My biggest problem with Google's action is that they are not just changing the transport, they are changing the API. They could have an XMPP compliant API and just have a bizarre transport, but this isn't the direction they are apparently going.

• Configuration of the client device. For safety purposes, several handsets automatically disconnect from the IP network after some time of inactivity from the user (Typically 5 mns).
• The problem raised Janne and Will concerning "responsiveness" is not so much a constraint since 1) XMPP applications are most likely targeted at high-end devices (with touch-screen, OS like Symbian Series 60, Linux, Windows mobile, etc.) and 2) users do not expect same near-real time responsiveness on handsets as they experience on PCs (e.g. a presence update of contact list every x minutes is fine on handsets, typing is not so easy/fast, etc.)
• Bandwidth consumption is a REAL concern for mobile devices because they are always on... Just check your average bandwidth consumption for your XMPP client on your PC and calulate how much it makes per month. You will be suprised...
• IPV6 is not a solution in the mid-term. Operators are relunctant to implement IPV6 on mobile networks (even if only on the edge, with IPV4 tunneling) as long as there are no real requests/needs
• Battery consumption is a real concern if using wi-fi

• Most mobile networks provided by carriers do not yet offer ip based connections.
• Because of 1 you can not connect to a mobile device, the device has to connect to you thus you can not push updates to the device without it first asking for one.
• The initial cost (time and power wise) of making a connection on a mobile device is usually much more of a concern than maintaining a connection and downloading data. I don't understand why Google would be concerned about actual bandwidth. The only reason this would be a concern is because it's prohibitively costly money wise for the data usage from a carrier.
• Decoding a compressed stream may tax a phone significantly to the point of non-responsiveness on the slower devices.

Finally, use techniques specially designed for Mobile devices such as Push gateways to signal the device when data is available for it to further reduce traffic and latency associated with polling.

+1 for Binary encoding. Do your development with the "verbose mode" and throw the binary encoding switch at run time.

There are couple of clients in the market that use specially designed proxies made for XMPP for the mobile environment that shift some of the heavy lifting to the server side.

So, I'm partly glad that Google went binary, and I hope it either is or will become a standard encoding.

This was also discussed in http://blog.dave.cridland.net/?p=45

(A binary encoding may potentially hurt extensibility, but I'm not sure about that argument—a sane encoding shouldn't weaken the data model.)

Compression can be applied to data independent of the protocol chosen and text data are good at getting compressed.

As time goes by mobile devices are getting more power and what seemed like a lot of data to transfer over mobile networks 3 years ago seems a very small amount today. Either that or we would all be using WAP and nobody would be even dreaming about looking up a Google map (what, downloading large images to a mobile phone?!) on an iPhone.

P.S. Would a binary protocol solve the 3rd key issue that you mentioned - power consumption?

@Andrisi: I'm not sure what "price" you are referring to. With stream compression, XMPP streams become quite compact.

Adam: The thing is that IPv4 is used as an transport. If you change that, you do not need to change IPv6-address, as long as your new IPv4-address can reach you home server, where you have your real IPv6-address. Thats why it is mobile. You can even do better tricks with IPv6.

And if you use your phones GPRS, GSM whatever, you will have a constant IPv4 (and later IPv6, I hope) address, as long as you have connection to your phone companies GPRS, GSM or whatever. You can even switch between them. It works for me, any way. And it is NOT much data used for XMPP, as I have it on my phone and had checked my data trafic use.

You brought up the issues XMPP has with roaming between various IPv4 networks. I've been quietly wondering about this problem myself. You mentioned IPv6 as being the solution to this issue and that Teredo might be able to help fill the gap until we see more native IPv6 deployments. I was wondering though; if an XMPP client is connected via IPv6 facilitated by Toredo wouldn't the connection still be dropped when the underlying IPv4 connection is broken while moving between wireless networks? I admit that I'm no networking guru and have no experience with Toredo so I may be missing something (e.g. because Toredo is a UDP protocol and thus connectionless maybe the IPv6 tunnel is left intact when moving from net to net.)

Again thanks for the post.