Jabber

The stated focus of Jabber is to be a “conversational technology” for p2p in the most general sense, including not only person to person, but also person to application and especially application to application. Actually, Jabber more properly refers to a whole group of technologies that share common goals within an overall architecture.

Jabber (www.jabber.org) thus evolved as a project to bring together diverse applications, when a number of developers decided in 1998 to create a truly open, distributed p2p architecture as a basis for further specialized work. Jeremie Miller is credited as being behind that initiative. Public recognition came first in 1999.

The design began by choosing XML as a consistent way to encapsulate data, whatever the application, and yet allow arbitrary extension as the need arises. Application protocols are transparently implemented in XML and translated to native formats as required.

Some of the many projects developed within the Jabber framework are:

• Gateways to most existing IM services and their protocols

• Libraries for almost all current programming languages

• A modular open source server, plus client software for practically every platform

• A number of specialized services such as language translations

A particular emphasis is given to P-A communication (as introduced in Chapter 2) and to fostering a design approach that facilitates all p2p conversations (P-P, P-A and A-A), along with the access of dynamic data from many different services.

The first practical application of Jabber technology is as an instant messaging system focused on privacy, security, ease of use, access from anywhere using any device, and interoperability with IM, phone, and Web-based services.

Once again applying the generic list outlined in Chapter 2, Table 6.6 gives the component summary for Jabber IM.

Central to the open architecture is that all data transfer in any context occurs in XML format and protocol, which allows Jabber to function as both storage and exchange service for the applications. Metadata and structure are similarly defined in XML, and a number of working groups have set out standardized tag sets to describe useful namespaces for documents, music, and other content domains. Once defined, such tag sets allow meaningfully encoded data exchanges over other Jabber services, for instance in IM conversations that traditionally deal only with pure text.

So, although Jabber in theory can be many things, its most common implementation so far is to provide a general IM client, which is why Jabber is examined in this chapter. Using the service gateways, a Jabber client in principle allows a user to communicate with members of any of the major IM networks. The Jabber user must still obtain a valid user identity in each of these other IM systems, however, and must still “discover” which network a particular person might belong to (and which IM identity that person has).

Another development focus is the Jabber-as-Middleware ( JAM) project, which has its goal to make the technology a vehicle for discovering services, authenticating sessions, reliably delivering XML packets containing service requests and responses, and notifying senders that their packets have been delivered. This middleware concept is similar to what for example HailStorm/Passport does (see Chapter 2), only Jabber can do it in a distributed manner without the extreme central server dependency.

Infrastructure

Jabber infrastructure has some specific points worth expanding on, mainly because its focus is on generalized resources, rather than just IM identities. In particular, the Jabber IM system (not the general Jabber infrastructure) is distinguished from existing IM services, such as those discussed earlier, by several key features:

• XML foundation (structured, intelligent messaging; P-A, A-A)

• Distributed network (arbitrary number of servers/services)

• Open protocol and codebase (interoperability)

• Modular, extensible architecture

The underlying model that Jabber is based on is Internet e-mail—a distributed network of servers that use a common protocol, to which specialized clients connect to send and receive messages. In the case of Jabber, this also means other services. The main functional difference from e-mail is that Jabber incorporates presence and is close to real-time communication, unlike the store-and-forward e-mail model.

Servers are fully independent of each other and maintain their own user lists and services. They transfer messages and presence information among themselves in an atomistic p2p network, as in Figure 6.7. Any number of Jabber servers can form a network. A particular user is always associated with a specific server with an identity that looks like an e-mail address: [email protected]. This identity is assigned in a registration process or during administrative setup of a server (enterprise).

Identity

Choosing to format Jabber user identity in a format similar to an e-mail mailbox identity has immediate benefits. Partly, this is socially established and accepted, and it allows services and companies to resolve and manage user identities in ways that align with existing policies. It also defines a social (or chat) context for the user.

Based on the identity, a Jabber application can expose internal data to public access. A fully qualified external URI would thus take the form:

jabber://user@server/resource/data 

This is a fully generic notation and translates directly to how Jabber clients manage peer access using XML.

Transport Agents

The theory is that the Jabber server(s) can implement functionality that can interface with other peer or messaging systems—Jabber calls these interservice interfaces jabber transports. Such server-side programs are easily added to the core server to provide arbitrary enhanced functionality to the end user.

For example, a user with a Jabber client connected to jabber.org can invoke its ICQ agent at icq.jabber.org. This server component then acts as a transport to the normal ICQ service, translating between Jabber XML and the other system’s protocol. This currently assumes that the user already has an ICQ identity and that the other system will accept third-party connections. In a like manner, aim.jabber.org would do the same for a user registered with AIM, and irc.jabber.org acts as a feed for a selected IRC network.

There is no a priori constraint on what kind of gateway service a Jabber server can provide. Because Jabber is a prototype system, as yet only a few transports are deployed, and a user might often be unable to contact the agents. As noted earlier, AOL actively discourages such interoperability with AIM and ICQ servers, even by its own subscribers who wish to use another software, and Jabber transports are no less affected than other third-party clients in this respect. Figure 6.8 shows a recent server status page for jabber.org; the long AIM and ICQ transport downtimes highlight the AOL noninteroperability problem mentioned earlier. In addition, the requirement for an already registered identity for services like ICQ or AIM means even when it works, you can’t (in Jabber) join as a new user through a gateway.

The following is from a recent update of the Jabber FAQ on the matter:

Unfortunately, for the last few months AOL has been actively working to block AIM subscribers who wish to connect to AIM through Jabber’s AIM Transport. While jabber.org programmers have addressed these blockage attempts through various means (including updated versions of the AIM Transport), at this time some public Jabber servers have not yet installed the most recent versions of the AIM Transport (thus disabling communications with AIM), and even those servers which have installed the most recent versions may be experiencing intermittent communications to AIM. We apologize for the inconvenience and sincerely hope that AOL, along with all other providers of IM services, will work together for true interoperability.

This is clearly a problem that’s not going to go away anytime soon.

Clients and Servers

On the face of it, Jabber has a marked client-server architecture, in that clients log in to a Jabber server prior to any p2p exchanges, and Jabber messages between clients are relayed through the server. Each client session initializes an “XML Stream” to the contacted server, and the stream lasts for the duration of the online session.

Direct peer connections (for example, file-sharing sessions between clients) are defined as application-specific connections—perfectly possible, but they must first be negotiated in the client-server context that at minimum conveys address and presence information. This is similar to the ICQ and AIM model.

Part of the design philosophy for Jabber was to move much complexity (such as transports) to the server component. This makes it easy for developers to create clients, and easy for server administrators to add new functionality without requiring massive client updates. The Jabber server core is relatively small, so that each machine could in principle have its own embedded Jabber server, which would equate to atomistic p2p from the user perspective.

The Jabber system is designed to support simple clients, imposing very few restrictions. The client need only at minimum be able to

• Communicate with the Jabber server using TCP sockets

• Parse and interpret well-formed XML packets

• Understand message data types

The use of XML is an integral part of the architecture because this markup can express almost any structured data. All Jabber components must speak XML within the system, even transports that might use other protocols externally. At the same time, Jabber doesn’t care about the delivery medium. Thus, it places no inherent restrictions on the delivery system and requires no built-in knowledge about it.

Numerous client implementations are available, and the alternatives are described at www.jabbercentral.org. Most developers would tend to recommend WinJab for Windows, Jabbernaut for MacOS, and Gabber for Linux. Figure 6.9 shows the configuration dialog for the WinJab client, indicating the kind of profile the user sets up. The client normally uses HTTP port 5222, or 5223 if SSL (Secure Socket Layer, encryption based on digital signature exchange) is activated.

Running the client illustrates how available resources can be browsed in separate windows, as seen in Figure 6.10. The server informs the client which services are implemented and thus visible, while browsing them adds further information. This is in addition to the expected IM functionality localized to the main application window and its roster list: status notification, IM, chat, file sharing, and so on.

Anyone can download not just the Jabber client software; the server software is equally open and available, which lets anyone set up their own Jabber-based network. The corporate face of Jabber (jabber.com) is dedicated to deploying business solutions based on the technology.

Server software and source is distributed under the Jabber Open Source License (JOSL), an OSI-approved open source license similar to the Mozilla Public License (MPL). MPL-derived licenses narrow their definition of derivative works, focusing on the actual source code files. This enables developers to write additional modules without necessarily making those modules open-source, while at the same time ensuring that any modifications to the original source code for the Jabber server are contributed back to the Jabber community for possible incorporation.

The core Jabber server includes components for

• Session management (login, presence tracking, and so on)

• User identity management (registration, authentication, profiles)

• Client-to-server communication (by extension, client-client messaging)

• Group chat management (many-to-many)

• DNS resolution (Internet domain names are used for server identity.)

• Server-to-server communication (also part of the messaging chain)

• Database lookups (for registered user list, etc.)

• Storing and retrieving offline messages, vCards, and other data

• Filtering messages based on user preferences

• Server-side application management (such as transports)

• System logging

Of particular interest is that the notification subscription service can pass on presence information to and from any entity that has a Jabber identity. This includes foreign entities that are connected over translating transports.

Jabber Protocol

Messages in Jabber are wrapped in one of three top-level XML type containers: message, presence, and info/query (iq). The structure and syntax is otherwise very simple and human-readable, and “raw” messages can even be typed in over telnet— the simplest supported client. An example:

<message to='user@server' type='chat'> 
 <body>The actual text of the message.</body> 
</message> 

A “from” attribute with sender identity is added by the sender’s server. Clients might add, at their own discretion, an “id” attribute for internal tracking purposes.

The type specification is also optional; it defaults to a normal message type. Type “chat” assumes that the client displays this in a chat window, typically line-by-line. Other supported types are group chat (addressed to chatroom relay service), and error (its message held in an error container).

Other optional message element containers are:

• html, marks an alternate namespace for the message, like the multiple format convention for e-mail, based on XHTML 1.0 BASIC

• subject, user designated

• thread, client generated for reply tracking (usually formed from a hash of the sender’s Jabber ID and the current time)

• x, which is an extension mechanism, or is used to send commands

The use of the “x” element requires that a separate namespace for it be declared, the range partially overlapping the info/query namespaces. Currently supported namespaces (basic functionality) are listed in Table 6.7, for both x and iq types.

Jabber identity (jid) types are a way to structure available resources, rather similar to how MIME can type content. Currently supported jid types include application, conference, headline, keyword, render, service, and user. These types are used extensively when browsing resources. The following example shows a browse query sent to a server, using iq type get.

<iq type="get" to="jabber.org"> 
 <query xmlns="jabber:iq:browse"/> 
</iq> 

The server would respond with a nested series of containers that describe the resources and services available. An abbreviated result example is shown.

<iq type="result" from="jabber.org"> 
 <service type="jabber" jid="jabber.org" 
  xmlns="jabber:iq:browse"> 
  <service type="jud" jid="users.jabber.org" 
   name="Jabber User Directory"> 
   <ns>jabber:iq:register</ns> 
   <ns>jabber:iq:search</ns> 
  </service> 
… 
  <conference type="private" jid="conference.jabber.org" 
   name="Private Chatrooms"> 
  </service> 
 </service> 
</iq> 

Similar browsing can be applied to each of the jid levels to find further detail relevant to each. In typical Jabber clients, this is abstracted in a browser window with clickable icons representing the various entries, much like browsing a filesystem hierarchy.

The iq type set is used to provide required information to the server, for example in order to join a discovered conference. More detail of such client-server conversations is given in the official Jabber Protocol Overview document, available as www.jabber.com/pdf/protocol.pdf, or in online readable HTML at docs.jabber.org/general/html/protocol.html.