Instant Messaging and Presence on the Internet
MEMBER BRIEFING 9 < Main Index
|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:
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:
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 (gaim.sourceforge.net) or Proteus (www.indigofield.com); 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.
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.
Expanded Coverage from ISOC
In-depth articles, papers, links and other resources on a variety of topics
are available from the ISOC site at: www.isoc.org/internet/issues
Examples in the News
Oct 14, 2002 InformationWeek
Reuters has been looking closely at IM since 1999, when it learned of the underlying presence awareness-the ability to detect a persons 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
Presence and Instant Messaging Protocol
Instant Messaging and Presence Protocol
SIP for Instant Messaging and Presence Leveraging Extensions
Relevant IETF RFC's
3342 The Application Exchange (APEX) Option Party Pack
About the Author
Harald 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
4, rue des Falaises
Series Editor: Martin Kupres
Copyright C Internet Society 2005.