Cisco plans to use Jabber.com to "enhance the existing presence and messaging functions of Cisco's Collaboration portfolio." Cisco already owns web conferencing product WebEx, along with other Internet products such as enterprise social networks Five Across and Tribe.net. So Jabber.com will prove a handy addition to their growing portfolio of enterprise-focused Web communication products.

As for the protocol Jabber, it is used in many messaging products on the Web - from Twitter to Google Talk to Meebo, and more. It's also used to make AOL's AIM, Yahoo Messenger, and Microsoft Windows Live Messenger interoperable. To explain more about what Jabber the protocol is, here is an extended excerpt from a post Marshall wrote in January:

Jabber Explained In Simpler Terms

In simple terms and to the best of my understanding, the http protocol used by web pages is said to be inefficient because it requires a user's machine to poll a server periodically to see if any new information is available.

Quite often there is nothing new and energy has been wasted. Think of how often Gmail checks to see if you've got any new emails (every two minutes) or how many times your RSS reader pings all of your feeds to see if they contain any new items. Meanwhile, the time between polling leads to a delay in updates.

That might seem like a small burden to you, but multiply that times everyone using these services and there's a lot of inefficiency. Sometimes that inefficiency can define the technical limits of what a service is able to do. On an individual level, I know I'm unable to use Google Reader because I have enough subscriptions that it times out checking every single one of them for new information. I wish it would just chill out and wait!

This is not a problem experienced in the world of Instant Messaging. While there are too many IM protocols in the world, a growing number of IM clients, including Google Talk, use the open standard Jabber, or XMPP.

XMPP lets one party signal to any XMPP server that it is available to receive any new information that's being delivered. When another party sends new content through the XMPP server, the message is passed on immediately and automatically to all recipients who are marked as available, basically.

What Could a Future Built on Jabber Look Like?

Ask yourself what a decentralized, open source infrastructure for real time communication could offer. A lot. As an RSS-head, I'd love to see XMPP let my various RSS clients do more faster and get bogged down in fewer unnecessary activities. RSS is all about speed for me but clients can only do so much so often when they have to pester someone else's server every time they want to check for new information. Those delays can be of real consequence.

The Tivo example is just one of many possibilities in the realm of machine-to-machine XMPP communication. Automated alerts are useful in all kinds of more serious use-cases and why use polling to monitor changed conditions when you can use an open source protocol that can make presence and real time communication scalable?
Counter Arguments

The primary arguments against a future powered by XMPP are two. First, so much of what's already been developed is web-centric, based on http, that the options for mashup-fodder are relatively limited for XMPP. For a service to integrate a number of new and existing communication features, making the leap to a less ubiquitous protocol might not make sense. Time will tell if things like IM, Android and software like Jive's can change the near total imbalance in marketshare between communication protocols online.

The second argument against this rosy picture of the future could be that open standards-based technology falls outside the profit model of many larger companies. If one vendor can corner their respective model with proprietary technology and charge a monopolist's premium for superior service, then a standards based competitor will have their work cut out for them. Google Talk's use of XMPP may have been the straw that broke the camel's back in IM because the chat client rode the coat-tails of so many other Google services.

It's hard to know what role these obstacles will play in the future, but it is exciting to think about the possibilities that a standards based approach like XMPP offers for real time communication. No one will want to wait for a web page to load if a significant portion of the internet starts working as free of friction as IM does today. Enable that communication to go on over a decentralized system based on open standards and you're talking about a whole new world.

See discussion around this on the post Could Instant Messaging (XMPP) Power the Future of Online Communication?.