Instant Messaging and Presence on the Internet


11 November 2002 By Harald Alvestrand

Instant Messaging and Presence - the function of being able to see if people are logged in on the network, and send them messages in real time - has proved one of the most popular applications of the Internet, causing people to want to stay connected to the Internet for inordinate amounts of time, and fostering a sense of "online community" that perhaps no other application has done.

But paradoxically, instant messaging and presence has also been one of the hardest functions to standardize for the Internet.

This briefing explores the conflicting interests that underlie the basic problem of allowing people to utilize a standards-based instant messaging functionality over the Internet.

Instant Messaging - concepts

While some aspects of instant messaging may seem intuitive, there are actually multiple features that interact to form your environment. These include:

  • User identity - what identifies you as a user? This ranges from username@host/password on some systems, "I claim to be this user" on Internet Relay Chat (IRC), all the way up to certificate-based, cryptographically signed identities on experimental systems.
  • User directories - how do you find out which users exist, and what are the rules for accessing it? This again ranges from nonexistent (IRC) to ad-hoc and voluntary (Jabber) to essential and richly protected (AOL).
  • Presence - how do you know if and where another user is available on the Net?
  • How do you control who is allowed to see your presence, and how much information you reveal about yourself?
  • Person-to-person messaging - what can you send, and how do you know if the recipient can handle what you want to send to him?
  • Conversation support - is a message a message, or is it one line in a "conversation"? Most IM interfaces provide the concept of a "chat window" where users type at each other in a "my line, your line" fashion.
  • Chat room support - is it possible to set up rooms where many people can talk as a group? What's the control paradigm for chat rooms, and how is it enforced? In IRC, these are the real point of the whole system; in other systems, they seem to be added as an afterthought to the person-to-person chatting.
  • Additional features - there are IM clients decked out with file transfer, voice chats, video chats and more.....

How those features are designed, how they work together, and how they interact is part of what will shape the experience of the user community, and thus shape both the size and style of the user community for a particular IM environment.

Some issues - such as what an identity is, when you are obliged to show your identity and when you are allowed to be anonymous, how you prove your identity to others, and how hard it is to fake identities on the systems - are at the core of the IM systems. For instance, if anonymity is easy, attempts to control spam and antisocial behaviour become much harder; if anonymity is not allowed, people may refuse to use the systems because they feel that they are giving up too much privacy.

Building a community

Anyone who has used an IM will tell you that the most important feature is that you can reach your friends through it. And also, many will tell you that an IM system is a great way to make friends. This creates two ways in which you are encouraged to grow the community:

  • If you use a particular IM system, you will encourage others to use the same, so that you can contact each other.
  • Using the functions of the chat rooms, you will get new acquaintances using the same system, increasing your commitment to and usage of that particular system.

The traditional wisdom is that the value of a community grows roughly as the square of the number of members; thus, being members of a large community is better than being members of a small community.

The opposing view is that a community consisting of the people you work with is more valuable than a large community of people you don't know - for instance, this is the dominant thought behind enterprise-internal IM systems, one of the largest markets for IM software (as opposed to IM services) today.

In certain environments (like IRC), there is also a real human cost associated with making networks large - I believe this is the basic driving force behind the unique IRC phenomenon known as a "netsplit", where an IRC network splits into several networks that go their own way without contact with each other; it seems to occur somewhere between 10.000 and 100.000 users on a single IRC network.

The value of a community is not only to its members, however; many chat systems are financed by advertising, and some (AOL, for instance) are quite aggressive both in promoting their advertisers and in attempting legal action against those who wish to take advantage of the community without viewing the advertising. This has also produced the traditional problems with interworking, in that the charging models for different services differ, so that what is billed in one network is free in another, and vice versa - making interworking, even when technically possible, administratively impossible.

Linking communities through bridges

When faced with multiple communities of communication, the traditional means of linking them has been through gateways: devices that are able to talk the protocols of multiple systems, and translate messages between them.

The classical example in the IM world is Jabber, which started out as a server that would enable a client to talk to multiple IM systems through gateways at the server; it's since grown into an IM system on its own, too.

The disadvantage of the bridge approach is that only a "least common subset" of functionality is guaranteed to be supported across the board; other features will either work part of the time or work inconsistently based on who you're talking to.

Security is also very problematic across bridges. By far the most secure and simplest solutions to security involve user-to-user encryption and digital signatures; having gateways in the middle that translate messages between protocols is completely anathema to such a security approach.

Another approach is multiprotocol clients, such as gaim ( or Proteus (; this will allow solutions to the security problem, but will require that people establish identity on each of the networks on which there are people they want to communicate with.

Still, these approaches are working today, and needs nothing but documentation and freedom from legal action to prosper.

Merging communities through common standards

A more future-looking approach is to actually define a common set of functions that all systems should support, and attempt to get a few well-defined ways to transport this functionality between systems. In an ideal world, this would enable one to communicate with any IM user anywhere (provided that you know his ID, and he wants to listen to you), and take advantage of additional functionality when available.

It is harder to achieve, because it requires significant players to agree upon a standard, agree to follow the standards, and refrain from all the little "helpful extra functionality" that allow them to try to keep their customers limited to their original community.

The benefit to the user community is large - the set of participants one can engage in IM functions grows with the total number of users on the Internet rather than the number of users of any particular service, and a common service definition allows one to choose the service provider that has an appropriate functionality, and an user interface that has appropriate functionality, rather than being locked in to "the service provider of my friends" or "the user interface of my service provider". And the need to run multiple IM clients simultaneously should become a thing of the past; with properly designed security, there should be little problem in linking to a company-internal IM/P service, a commercial "open" IM/P service and a private "hobby" IM/P service at the same time through the same user interface.

This, of course, goes straight to the revenue stream of service providers who base their revenues on advertising or bundled services; if the user can choose any user interface, he or she is very likely to choose one that does not show annoying ads or popups - which will make it much harder to sell those ads and popups to the advertisers. And when unbundled IM services are available in a competitive market, the ability to lock in customers by keeping control of their IM experience becomes that much smaller.

But to the end user - whether it's a private person or a company seeking to utilize IM in its internal processes - should benefit.

Overview of current IETF activities

The IETF, in keeping with the model above, has chartered multiple IM/presence-related activities.

  • The IMPP working group, working on the common service definition, is in the last stages of creating the "Common Presence and Instant Messaging" format definitions (CPIM for short), defining a common minimum set of messaging and presence functionality, with security functions appropriate for end-to-end security - in practice, this means support for digitally signed messages from sender to recipient.
  • The SIMPLE, APEX and PRIM working groups are defining ways in which to transport such common-functionality messaging objects across the Internet. The reason for the multiple groups is that they have differing philosophies they want to try; SIMPLE builds on the SIP infrastructures, APEX is defined in the spirit of the store-and forward "email" model, and PRIM is trying to keep things "as simple as possible" by building protocols straight on top of TCP.
  • Recently, the group working on Jabber has come to the IETF asking how they can interface their quite successful IM protocol suite to the IETF-defined functionality, and in the process publish a document set that defines a baseline set of standards for how Jabber operates. Discussion is still ongoing.

So far, the IETF has invested minimal resources in "added value" IM functions such as user directories, chat rooms or extended functionality. These are very interesting topics, and we need to keep them in mind while designing the basic functions, but the basis needs to be in place before we can get there.

The work on IM in the IETF has taken a long time, and is not likely to be finished soon. The CPIM specs have been "nearly finished" for a year, but still lack the final edits. The APEX message-passing protocols are published, but the presence functionality is still waiting for the CPIM presence definitions to be finalized. Jabber is not yet an approved working group, but hopes to be so before the November 2002 IETF meeting.


Instant messaging is an important technology for very many Internet users. At the moment, the instant messaging marketplace is fragmented, and some participants derive a significant benefit from keeping it that way.

Getting standardized IM deployed on the network will significantly benefit end-users, but needs significant effort for it to be designed, developed and deployed.

The IETF has multiple efforts going on that attempt to make standards that are possible to deploy. Once those are finished, we hope that we are one step closer to the goal of truly interoperable instant messaging systems.

This article is also available in PDF and ASCII

Expanded Coverage from ISOC

In-depth articles, papers, links and other resources on a variety of topics are available from the ISOC site at:

Examples in the News

Oct 14, 2002 InformationWeek
With its Reuters Messaging, developed in conjunction with Microsoft and 30 financial-services companies, the news agency aims to provide a secure IM tool where messages can be logged that will help financial-services companies meet any future Securities and Exchange Commission requirements regarding the archiving of IM exchanges.

Reuters has been looking closely at IM since 1999, when it learned of the underlying “presence awareness”-the ability to detect a person’s online status-and determined that it would revolutionize the use of applications, says chief technology officer Mike Sayers.

For More Information

IMPP Working Group

Extensible Messaging and Presence Protocol

Application Exchange

Presence and Instant Messaging Protocol

Instant Messaging and Presence Protocol

SIP for Instant Messaging and Presence Leveraging Extensions

Relevant IETF RFC's

RFC 3342 The Application Exchange (APEX) Option Party Pack
RFC 3341 The Application Exchange (APEX) Access Service
RFC 3340 The Application Exchange Core
RFC 3339 Date and Time on the Internet: Timestamps
RFC 2778 A Model for Presence and Instant Messaging
RFC 2779 Instant Messaging / Presence Protocol Requirements

Related Organizations

About the Author

Photo of Harald AlvestrandHarald Alvestrand was born in Norway in 1959, and graduated from the Norwegian Institute of Technology /NTH) in 1984. He has worked for Norsk Data, UNINETT (The University Network of Norway), EDB Maxware and, since, 2000, for Cisco Systems. His current title is Cisco Fellow.

He has been active in Internet standardization since 1991, and has written a number of RFCs. He has been an area director of Applications and of Operations & Management in the IETF, as well as a member of the IAB, and is currently serving as IETF Chair.


The ISOC Member Briefing series is made possible through the generous assistance of ISOC's Platinum Program Sponsors: Afilias, APNIC, ARIN, Microsoft, and the RIPE NCC, Sida. More information on the Platinum Sponsorship Program...

About the Background Paper Series

Published by:
The Internet Society
1775 Wiehle Avenue, Suite 102
Reston, Virginia 20190 USA
Tel: +1 703 326 9880
Fax: +1 703 326 9881

4, rue des Falaises
CH-1205 Geneva
Tel: +41 22 807 1444
Fax: +41 22 807 1445


Series Editor: Martin Kupres

Copyright C Internet Society 2005.
All rights reserved.