Messaging Technologies

At the time of writing, the IM market is in the grip of what we could well call the “ IM Wars”, akin to the intense “browser wars” that characterized the last decade before Internet Explorer became the dominant Web browser.

The similarities to the browser wars are striking in that intentional incompatibilities are incorporated to prevent interoperability between rival clients, and that the rival companies are fiercely competing for users by offering ever more features and extensions to the basic messaging service. A series of buyouts have restructured part of the market, so that for example Miribilis ICQ, dominating the IM field, was acquired and incorporated into AOL with unclear aims for the future. Microsoft as usual went its own way and completely changed the way it was involved in the IM market, retiring established services in favor of new variations.

Some IM Concepts

Before getting into the implementation specifics, it can be useful to overview the concepts and issues that IM technologies should address. Some were introduced earlier, but they are summarized here more systematically.

IM is at bottom a peer extension of chat and exists in that respect parallel to IRC as a form of person-to-person communication. Figure 6.2 depicts the difference between the two messaging technologies in the form of simple connectivity diagrams, highlighting the fact that IM clients establish p2p connections to exchange messages. In IRC, even private messages must always pass through the central servers that clients connect to. At least that’s the theory, some IM (notably AIM) clients do in fact server-relay in a manner similar to IRC private chat, but they are then tightly bound to a single service, unlike the IRC peer server network.

IM implements two core functionality concepts:

• Individual presence, as a means of finding, retrieving, and subscribing to changes in for example “online” or “offline” information of other users.

• Instant messaging, which is a means of sending small, simple, private messages that are delivered immediately to identified online users.

The latter immediacy is the major reason why presence information is so important. Taken together, these two explain why IM achieved its popularity. ICQ and AIM alone registered some 50 million users in just two years.

But IM also requires a third concept, not present at all in IRC:

• Unique and persistent global identity, which allows users to find each other and exchange messages, and the IM service to track user presence.

Strictly speaking, IM fudges identity a bit, because the implementations track only registered clients or user-supplied nicknames. Importantly, however, IM systems use their own directory services to bind unique numbering, user nickname, and current IP address into a workable addressing scheme that, when seen from the user perspective, is independent of the underlying Internet infrastructure’s IP and DNS addressing.

Enhancing the Experience

With the effective disappearance of Napster, several IM clients began to offer the ability to exchange music (or other media) files, albeit usually with some restrictions on which files, transfer features, and performance.

The offerings could include the purchase of commercial MP3 tracks. For example, Sony set up Pressplay, an online-digital-music joint venture with Vivendi Universal. Rival AOL invested in another music service, Musicnet. However, it dropped a similar feature from its messaging service in 2000 that allowed users to search for music files due to concerns about possible illegal copying.

Another, less contentious enhancement is the addition of various “push channels” to promote various forms of broadcast content, and the availability of public chatrooms similar in flavor to what IRC provides.

Recent clients, such as ICQ’s latest, described later, are really tending towards becoming full-featured personal information managers (PIM). They offer management of address books, to-do lists, e-mail services, reminders, notes, special interest group tracking, banner exchange programs, and so on. Other p2p services include various games, Web phone connectivity, send SMS, pager—the list just seems to grow all the time, along with the size of the client downloads.

Standardizing Basic Concepts

Like many Internet technologies, IM is defined in a “memo”, here known as RFC 2779 “Instant Messaging / Presence Protocol Requirements”, which sets out some of the fundamental terms and minimum functionality descriptions that IM implementations should adhere to.

RFCs do not as such constitute a formal set of standards, but they should be seen as precursors to standard proposals. They are therefore often used by developers in lieu of formal standards in the interests of promoting interoperability. The abstract in RFC 2779 describes the current IM situation succinctly:

Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. ... Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol ( IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.

This work (www.imppwg.org), under the overall supervision of the Internet Engineering Task Force ( IETF, www.ietf.org), is expected to result in a consensus adoption of a truly open standard protocol for future IMPP implementations. The importance of this for coming mobile Internet is stressed later in the document:

It is expected that Presence and Instant Messaging services will be particularly valuable to users over mobile IP wireless access devices. Indeed the number of devices connected to the Internet via wireless means is expected to grow substantially in the coming years. It is not reasonable to assume that separate protocols will be available for the wireless portions of the Internet.

Based on this expectation, the RFC recommends that the protocol implementations be especially designed for typical mobile contexts, tolerating high latency, low bandwidth, and intermittent connectivity. In addition, they should make modest requirements on computing power, device battery life, and screen size.

Minimum Functionality

Based on experience and the RFC, one can formulate some basic requirements that all IM technologies must implement, at least in future.

The protocols must allow a presence service to be available independent of whether an instant message service is available, and vice versa. These functionalities are seen as independent. It’s also a practical requirement that message inbox and presence entity (termed presentity) be decoupled and fully independent of each other, even if they share the same identifier (in the supported namespace).

Interoperability is a core requirement, according to the RFC, which contrasts with the current fragmented deployment of IM. Support must include a minimum set of protocol features and a common message format.

User control is specified to span such things as instant and subscriber visibility, and the kind of information that others may see. IM (and chat) clients almost always implement some way for users to set different levels of presence, including “invisible” or DND (Do Not Disturb). There should also be adequate control over access to inbox services and who can send messages to the inbox. As a rule, this control is implemented as some form of filtering—for example, an ignore list. Both forms of control are required by the RFC to be implemented at least in part as autonomous agencies, capable of responding even when the user is not available, or perhaps even offline (in which case, it must be mediated by an IM server). These requirements apply especially to the functionality of subscribing to presence notifications.

What the RFC specifically calls for is a common presence format that includes adequate identification information along the lines of the vCard “visiting card” exchange format now broadly supported by e-mail clients and PIMs.

Areas that the RFC extends compared to current implementations are authentication and encryption. In general terms, the technology must ensure authenticated endpoints, noncorruption, nonplayback, and privacy. Current popular implementations lack most or all of these characteristics, which are otherwise commonly realized using public key encryption and digital signatures.

A Common Standard?

On 25 July 2000, a new industry standards organization, IM Unified (IMU), was created with the stated goal “to rapidly enable users of all members’ instant messaging services to communicate in a seamless, convenient, private and secure manner” (see www.imunified.org).

The founding members of this coalition were AT&T, Excite@Home, iCAST, the MSN network of Internet services, Odigo, Phone.com, Prodigy, Tribal Voice, and Yahoo. In August 2000, the organization made public a first set of technical specifications for an open, standards-based, interoperable instant messaging protocol to achieve this goal. Implementation was scheduled for the end of that year, but at the latest check (late 2001), only Excite@Home had actually made use of the IMU protocol in their Excite Messenger client.

It’s significant that AOL, the dominant IM player since acquiring ICQ, is not a member and evidently does not wish such interoperability unless it’s based on AOL’s own “internal” solutions. Partly for this reason, the IMU was seen by some merely as a marketing posture against AOL, rather than any serious attempt at an open interoperability standard. It also appears significant that the IMU Web site appears not to have been updated in over a year, since that announcement in August. The suspicion is that IMU was a blip, despite the claims made in mid-2001 by various IMU-member spokespersons that the technology is ready to go, only awaiting the working out of certain legal and logistical agreements between members.

However, both the IMU, and IM developers independent of IMU (such as Jabber) state an intention to adhere to the fully open IETF protocol specifications for IMPP, a work that was described earlier, when these become available. A successful early test of IMU interoperability with Excite@Home was nonetheless documented by Jabber (see www.jabber.org/?oid=1592).

True to form, Microsoft dropped out of IMU when it made MSN Messenger obsolete and opted for its own bundled all-in-one solution to beat everyone else. Thus, Windows Messenger is a brand-new instant messaging service that is exclusively tied into the Windows XP operating system, which features IM, video, telephony, file sharing, multimedia, and more, as part of the basic package.

By virtue of its inclusion in the operating system, the Microsoft solution could easily prove to become the dominant technology within a year or two—the next killer application—unless its own incompatibility with other Windows versions, or with NetMeeting H.323 and other established protocols, proves too bothersome.

There are things to both like and dislike about that scenario, including the way WM requires connectivity to the .NET Passport service (see Chapter 2) for authentication and to manage presence information. It’s therefore not surprising to find question and answer on the Web about how to remove WM from Windows XP.

A brief look at WM is provided at the end of this chapter.