From the Android SDK M5 API Changes Overview, Dave Cridland pointed out the following:

The com.google.android.xmppService package has been replaced by the com.google.android.gtalkservice package. This is driven by the fact that the GTalk API is not XMPP compliant, and will be less so going forward. The reason is that XMPP is too verbose and inefficient for mobile network connection, and the GTalk API will be moving to a binary encoding for the protocol between the client and the server.

I'll enumerate the implications and conclusions:

1. XMPP is verbose.
2. XMPP is inefficient for mobile networking.
3. A proprietary binary protocol would be more efficient for mobile devices.
4. The former Android xmppService API will diverge away from XMPP.

I think that this direction is unfortunate, and the reasons misguided. Read on, and I'll elaborate...

NOTE: This post seems to no longer be fully inline with my current position—which is that a new (as of yet undefined) UDP-based C2S protocol using EXI would be best suited for mobile devices. Such a thing would however still be XMPP. Edited 2009-07-13.

I'll tackle these implications individually:

XMPP is verbose

I find it hard to argue with this point. In fact, I actually agree: XMPP is verbose by design. It is a truly open protocol—so open in fact, you can (for the most part) learn how the protocol works by just examining the XML stream. This is important because:

• Verbosity makes debugging easier.
• Verbosity makes the protocol quick and easy to learn.
• Verbosity provides an implicit documentation of the protocol, making it truly open.

I do not think that there is anything wrong with verbosity itself. In fact, I seriously doubt XMPP would be as popular as it is now if it were any less so.

XMPP is inefficient for mobile networking

This is a point that I can understand, but fundamentally disagree with. In order to best explain why I disagree, first I should elaborate on why mobile networking is different at all from normal networking. When discussing mobile networking, the following factors are key: Bandwidth, Roaming, and Power Consumption.

Considering bandwidth: This is an understandable concern—especially in light of the "verbosity" of XMPP. A single XMPP stanza can easily be ten times larger than the contained message. Luckily, all of that verbosity is extraordinarily compressible. By using XEP-0138 (Stream Compression), bandwidth consumption can easily be decreased by a factor of ten or more. Lowering bandwidth also has the benefit of decreasing latency.

Concerning roaming: This is another understandable concern primarily because XMPP is a connection-oriented protocol. If you are using TCP/IPv4 as your transport, you are going to be disconnected whenever your mobile device gets a different IP address(which would likely be often). This would be extraordinarily disruptive. From this point of view, I can understand why the traditional transport method between the XMPP server and XMPP client would be undesirable. In the worst case, stanzas could be actually lost without warning. However, TCP/IPv4 is not the only acceptable transport mechanism for XMPP.

The best transport solution for using XMPP on mobile devices would be TCP over Mobile IPv6. Mobile IPv6 allows a device to roam seamlessly across networks while keeping the same IPv6 address, which allows connection-oriented protocols (like TCP) to continue uninterrupted. Combine this with Teredo, and you have a device that can use just about any wi-fi hot spot for connectivity (even if it doesn't support IPv6 natively) and still retain the same IPv6 address. MobileIPv6+Teredo is a powerful combination that can easily be deployed to take full advantage of IPv6, and can be deployed right now.

If you get really creative, you can come up with some less conventional XMPP transports.

Concerning power consumption: This is arguably the most important consideration for mobile networking. The key to conserving power is making sure that the device is asleep as often as possible. If a device has to wake up every few seconds to process random presence stanzas and send TCP ACK packets, this can understandably cause some serious power consumption problems. This is a real concern because normal XMPP traffic between the client and server has a lot of what I can best describe as "background noise" stanzas.

A large percentage of this "background noise" that we receive on our desktop XMPP clients we simply don't (usually) care about on a mobile device. I would much rather have longer battery life than to have my friend's presence always up to date on my phone's roster. Luckily, it turns out to be quite easy to filter out most all of this background noise with existing XEPs, without neutering the XMPP implementation.

This is most easily achieved by using XEP-0016 (Privacy Lists) to block all incoming <presence> stanzas whenever the machine goes to sleep. This way, my phone won't be woken up whenever a random person on my roster goes idle, or changes a song on iTunes. The next time the machine wakes up because of user input, the block on <presence> stanzas would be removed. If I then wanted to view the presence on my roster, the device would then send a <presence> probe.

An unresolved issue is that of <iq> stanzas, which tend to get sent often when someone goes online. Often times these stanzas are useless jabber:iq:version queries which some XMPP clients (coughiChatcough) send to everyone who is 'available' on their roster. Bad, naughty XMPP client.

One possible solution to the <iq> stanza issue is to block them like <presence> stanzas. However, this is undesirable because it would make other users unable to initiate Jingle connections to your device whenever it is asleep. Other than to twist the arm of some of the various naughty XMPP clients to change their implementation, I'm not sure what a good solution would be. It is a problem that I think could be easily resolved, even if it meant a new XEP.

A binary protocol is more efficient for mobile devices than XMPP

In order for a proprietary binary protocol to be more efficient for mobile devices, it would need to be shown that the existing XMPP protocol is not efficient for this purpose. While I would agree that a naïve XMPP implementation would run into some serious problems on a truly mobile device, I hope I have illustrated above why the protocol itself is not the problem. I can think of no viable reason why a proprietary binary protocol would outperform a reasonable mobile XMPP-native implementation.