Volume Number: 17 (2001)
Issue Number: 06
Column Tag: MacTech Online
by Jeff Clites online@mactech.com
Last month we began our coverage of P2P (peer-to-peer) technologies. The P2P field is being fueled by open-source projects which have sprung up in response to the popularity of specific proprietary applications in this genre, by generalizing, improving, or simply imitating them. Last month we discussed Gnutella, an open-source protocol for peer-to-peer sharing of files and other resources. Gnutella was inspired by Napster, generalizing the concept to support sharing of things other than music files, and decentralizing searches to avoid any one critical point which could be attacked, by either technological or legal means. This month we are going to look into Jabber, which takes its cue from instant messaging (IM) and chat products such as AIM (AOL Instant Messenger), Yahoo Pager, MSN Messenger, ICQ, and IRC. Jabber's goal is to provide a "universal" XML-based platform for instant messaging, which can bridge to other protocols as well as support new applications of messaging.
Jabber originated with Jeremie Miller's frustration with having to use multiple pieces of IM software in order to keep up with all of his friends, who were using a variety of different IM systems. His response to this proliferation was to come up with a protocol which was designed to both serve as a messaging platform on its own and to transparently bridge to others, so that he could use one protocol (and one client application) to communicate with all of his friends. Unsurprisingly, he chose XML as the basis for Jabber. So what is Jabber, exactly?
Jabber isn't a specific application, and the Jabber community likes to point out that it isn't a protocol either—they prefer to call it a platform. In truth, Jabber represents a collection of XML-based message formats, and the protocol for communicating them.
Jabber is completely XML-based, and communicates over client-server based TCP/IP connections, modeled on the email system. Users are identified by Jabber IDs, which resemble email addresses, and are of the form user@server/resource. (The "resource" portion allows the same user to connect multiple times from different applications or locations, and so the name of the client application or location, such as "home" or "laptop", is often used.) Jabber users begin a session by connecting to their local Jabber server. Messages are sent by addressing them to other Jabber IDs and handing them off to the local server, which routes them to the remote user's server in a manner similar to how email is routed and delivered. The remote user then receives the message via a connection to his local server.
Jabber's design philosophy takes XML seriously, and also sees as fundamental the placing of the bulk of the logic on the server. As mentioned above, one of Jabber's original goals was to bridge to other IM system, so that Jabber users could talk to other IM users without either really having to care or fully realize that they are using different systems. The technology which allows this accordingly lives on the server side, and Jabber users bridge to other IM systems by having the server act as their proxy—from the point of view of the foreign IM system, the server is the AIM client (for example), and it takes care of translating Jabber messages into AIM messages, and vice versa. This translation is done by components of the server called "transports" (or more recently, just "components"). The value of this approach is that it makes the creation of Jabber clients relatively simple, and additional functionality can be added by upgrading Jabber servers, without requiring a widespread client upgrade.
But Jabber doesn't just bridge to other systems—in the ideal situation, everyone could just use Jabber natively. As an IM technology in its own right, Jabber is full-featured: it supports "buddy lists" as well as notification of whether these users are currently online. It goes a step further than most other IM systems, in that buddy lists (called "rosters") are stored server-side, which facilitates notification of online status (called "presence"), as well as allowing users to connect to Jabber server from different machines using different client software without having to keep separate rosters in sync. Additionally, notification under Jabber occurs only with consent—a user must "subscribe" to another user in order to receive notification of whether they are online, and the other user has to authorize the subscription. This affords additional privacy, and could be used to combat spammers (by refusing messages from users to which one is not already subscribed, for instance). Also, Jabber supports the concept of traditional IM messages (which Jabber calls "chat"), group chats similar to IRC (called "group chat"), and more passive messages.
In additional to serving as a traditional human-to-human communication technology, Jabber is aspiring to serve as a mechanism for facilitating application-to-application (A2A) communication, or as a middleware to transport other types of messages. Fanciful potential applications include "smart" appliances which communicate in order to negotiate for resources (such as a coffee pot which turns itself on when the alarm clock goes off). As of yet, there don't seem to be any applications in this arena, and it isn't clear if this is a reasonable goal—other technologies such as Java's Jini have not seemed to take off in the "smart appliance" area, and for more traditional application-to-application communication there is already a great deal of underutilized technology out there, and the idea of an AI-like communication between desktop applications isn't realistically on the horizon. As a transport mechanism for other forms of inter-process communication there is potential, but Jabber doesn't have a clear advantage over the alternatives already available, and for some applications a protocol more directly designed for this task might work better.
In general, Jabber seems to suffer a little from what I would call the "premature need for generalization", and this is just one of the symptoms. Although Jabber is trying to be general-purpose, it's clear that it was designed with instant messaging in mind—for instance, its message types are "chat", "groupchat", "default", and "error". In truth, many of the new XML-based protocols today are trying to fill some perceived general need at the same time they are trying to fill a specific one. In general, I'd prefer to see a strong solution to a particular problem (such as the need for an open instant messaging protocol), and have generalization come later, if it's really needed and after some experience has been gained with the concrete application. Then, the original use could become one application of a more general technology, possibly after reimplementation.
Jabber is composed of open protocols and formats, and there are open-source implementations of clients and servers as well. The importance of this shouldn't be underestimated, in light of the proliferation of mutually incompatible, restrictive IM technologies. But the most valuable and immediately useful aspects of Jabber, in my opinion, aren't really the direct consequence of the "open source" approach: they are actually security-related. First, it's straightforward for companies to set up a private Jabber server behind the corporate firewall. This is actually more significant than it may sound, because despite the inherent insecurity of using AIM (for instance) for communication of confidential material, it's so useful that people often do it anyway. With Jabber, all of this communication can happen without the need for it to pass through an external server, whose security isn't under the control of its users. In the same vein, Jabber is incorporating support for encryption, both PGP-like procedures for the encryption of message content, and SSL for encryption of client-server and server-server communication. They do get points off, however, for not incorporating this from the start; we have enough insecure protocols which originated while the internet was a safe, private playground, and anyone developing new protocols today has no excuse for ignoring the need for some level of encryption as a fundamental component.
If you're interested in Jabber from a developer's perspective (or as a user, for that matter), the central hub of all things Jabber is Jabber.org. Here you can find developer documentation, as well as FAQs, user guides, and links to client implementations. Developers will want to look at the Technology Overview, the Protocol Overview, and the Programmers Guide, as well as the links to available code libraries. Also, those implementing Jabber clients in particular will want to check out The Jabber Client Developer's Cheat Sheet, which will help steer you around the "gotchas". For examples of some alternative uses of Jabber, take a look at DJ Adams' articles on the O'Reilly Network, or on his own Fun with Jabber site. Adams' applications use the Net::Jabber Perl module, which makes this sort of experimentation a snap, and you'll want to get your hands on this if you are Perl-savvy. He also has an experimental implementation of doing XML-RPC over Jabber. O'Reilly has some additional general coverage of Jabber, both on their portal site and in their Peer-to-Peer book, the Jabber chapter of which is available online. Finally, try Eric Peyton's Fire IM client for Mac OS X, which supports Jabber as well as a variety of other IM protocols, and keep an eye on JabberCentral for coverage of current related news.
Jabber - Open Source XML-Based Interoperable Instant Messaging and Presence Platform
http://www.jabber.org/
Jabber FAQ
http://docs.jabber.org/general/html/faq.html
Jabber Technology Overview
http://docs.jabber.org/general/html/overview.html
Jabber Protocol Overview
http://docs.jabber.org/general/html/protocol.html
Jabber Programmer's Guide
http://docs.jabber.org/jpg/html/main.html
Jabber Projects - Jabber libraries
http://jabber.org/?oid=71
Jabber Client Developer's Cheat Sheet
http://homepage.mac.com/jens/Jabber/JabberClientCheatSheet.html
You Have Mail! [Mar. 09, 2001]
http://www.openp2p.com/pub/a/p2p/2001/03/09/adams_1.html
A More Sensitive Mail Notifier [Apr. 13, 2001]
http://www.openp2p.com/pub/a/p2p/2001/04/13/jabber.html
Fun With Jabber
http://www.pipetree.com/jabber/
Net::Jabber
http://search.cpan.org/search?dist=Net-Jabber
XMLRPC over Jabber
http://www.pipetree.com/jabber/XMLRPC/
XML Messaging with Jabber [Oct. 06, 2000]
http://www.openp2p.com/pub/a/p2p/2000/10/06/jabber_xml.html
Jabber Works: Here's How [Oct. 06, 2000]
http://www.openp2p.com/pub/a/p2p/2000/10/06/jabber_works.html
Peer-to-Peer: Chapter 6: Jabber
http://www.oreilly.com/catalog/peertopeer/chapter/ch06.html
epicware: Fire
http://www.epicware.com/fire.html
JabberCentral
http://www.jabbercentral.com
