WAVE Report

IM Planet Spring 2003
by James Sneeringer
Wave Issue 306 3/7/03

February 24 - 25, 2003
Boston, MA

Instant messaging has fully arrived as an enterprise industry. With statistics like 84% of US enterprises that have IM usage, it is an application that any company with a network cannot ignore. At a minimum, IT departments will want overlay solutions to understand its effects on network usage and security, and HR departments will want to ensure that its use falls within company policies. But for many vendors, including Microsoft, IM goes way beyond instant text messaging. With its RTC server, Microsoft sees IM as the bridge to a communication system of the future with highly integrated voice, video, text, presence, and applications. Lotus recently announced that it would be tightly integrating its Sametime IM application with its Websphere server. And in many sessions, numerous companies discussed the possibilities for using IM for applications communication.

The term of IM has been re-defined, from the traditional IM paradigm of the buddy list, presence, and text conversation window, to a general term for any combination of real-time messaging with presence status. Presence, really, is the key attribute of IM, and what distinguishes it from similar technologies like SMS. The result is that IM is coming to be considered as a logical transport layer, capable of pushing dynamic status changes messages to a client in real time.

At this point every enterprise needs to ask itself several questions. The first is, to what extent, and for what, is IM being used by my employees? The second is, what do I want to do with it? As a communication technology, it can be difficult to quantify the ROI on IM usage, beyond several vertical applications such as customer call escalation, or brokerage communications. But as several people pointed out, it might be unfair to ask IT departments to justify the cost of a basic IM management overlay. After all, they didn't install the IM clients; the employees did. Even if the company wishes to stop all usage it will cost money to do so. And for financial and health care companies, and the accounting departments of public companies, there may be a regulatory requirement for logging of all IM usage, for an audit trail.

At a higher level is the question of the company's long-term communication strategy. IM is one of several technologies impacting enterprise communications, including WLAN, mobile data, and voice over IP. Microsoft sees IM as an integral part of the converged enterprise communications of the future, and the standard of SIP as the way to get there. But for many companies, the cost of a full enterprise IM solutions such as Lotus Sametime or Microsoft's RTC server cannot be justified. These companies will be looking more to leverage the free public IM networks, either with a management overlay from companies such as IMLogic or Akonix, or an enterprise solution from one of the networks themselves, such as AOL or Yahoo.


There are several themes that became evident during the conference:

A strong tension between enterprise solutions based on the public networks, and private, internal IM solutions.

This was on display in the first two sessions, with the Yahoo and IBM/Lotus reps taking the two respective sides in the debates. In two consecutive sessions they traded comments and debated the two approaches hotly. In general it seems likely that large enterprises are more likely to go with a full internal system like Sametime, while smaller companies will be attracted to the price savings associated with public network solutions.

IM enterprise solutions based on the public networks exist on a range, from a simple security, management, and logging overlay to existing public IM use, to a custom enterprise solution from a big networks (AOL, Yahoo, MSN) that hooks into the enterprise directory server. In most cases the overlays are provided by 3rd parties such as IMLogic or Akonix. These consist of a server that sits on the network between the users and the Internet, monitoring and controlling IM use. For many companies this is the next step after discovering how wide-spread IM use is in their organization.

Both Yahoo and AOL sat on the panel of the 3rd session of the day, and both have enterprise solutions, although Yahoo was by far the most vocal in pushing theirs (and the concept of public IM enterprise solutions in general). Their public IM enterprise solution is based on their network, with authentication of the user taking place on the Yahoo servers. The enterprise piece is providing the ability to local IT to secure, manage, and log (if desired) the IM. AOL's enterprise solutions provide an option to base authentication on the local directory, essentially "trusting" any IM user who is authenticated by that domain.

IBM/Lotus was pushing Sametime, with a completely different view of enterprise IM. In this view, the enterprise deploys Sametime for robust internal IM and collaboration. If they want to communicate with a partner or customer, they can negotiate and set up a connection between their internal networks, based on SIP/SIMPLE standards, which like MS, IBM is pushing hard. The rep could not stop talking about it. For IBM/Lotus, enterprise IM is basically internal, and the technical standard of SIP/SIMPLE will allow their customers to set up connections to other enterprise networks if they desire. The concept of free access to public networks is only barely considered, with a connection to the AIM network that (according to some on the show floor) is barely implemented. Microsoft seems to be firmly in this camp, although Windows Messenger is based on SIP/SIMPLE, and interfaces with MSN.

The need for IM to fit into existing corporate policies and IT.

Everyone agreed that a stock brokerage cannot have one of its brokers communicating with customers under the screen name "studbroker22." Yet, the brokerage firm who discovered this screen name could not even match it to a specific broker. If IM use is to become a legitimate part of business communications it must submit itself to the same constraints that exist on other communications. These include:

Naming convention

Like e-mail, enterprise IM needs a naming convention. This is to make identity clear, and provide more professional interactions. Most solutions seem to lean toward using the e-mail address as the screen name. For public IM solutions, the use of the domain identifier creates a possible revenue stream--the public network charges to provide the domain as part of the screen name. This may or may not be hooked into the private enterprise directory.


Hand in hand with naming convention is the ability to trust that the person behind the screen name is who they claim to be. Authentication is either hosted by a public network (such as Yahoo) and provided for a fee to enterprise users, or the enterprise IM solution hooks directly into the internal authentication scheme. IBM/Lotus emphasizes the selling point that their solution (unlike Yahoo) does not double-charge for authentication. AOL has a solution that can "trust" the enterprise authenticated users for a particular domain.


Companies pay a lot of money for virus protection software and services. Ideally the IM system will be able to hook into the existing security framework.

Content filtering

A brokerage must be able to search outgoing content for the words "guaranteed return," to protect themselves. In addition, many e-mail systems filter for inappropriate or harassing content. This must be available on IM as well.


Automated legal disclaimers are an important part of many corporate e-mails. IM needs that ability as well.


Standard IM travels as clear text. Like e-mail, some enterprises have a requirement for encryption of this text, to protect data while in transit.


IM spam is possibly even more intrusive than e-mail spam, since it can pop-up on the desktop without opening it yourself. This is a downside to using public networks for enterprise IM, according to IBM. But, Yahoo said to watch for an announcement on this from them soon.


Logging is a regulatory compliance issue for financial service companies, and some healthcare providers. The paper trail must be preserved for audits. In addition, there may be a requirement of ALL public companies to preserve some traffic, due to the Sarbanes/Oxley bill that makes CFOs directly responsible for the accuracy of their books. However, IBM stated that for many of their customers logging does not even make the top 10 list of desired features. In some cases, they adamantly do NOT want to log unless required to by law.

There is also a personal component--allowing individuals to store conversations locally. Most clients already provide this.

Using IM for application communication.

Going beyond people to people, this idea uses IM as a real-time communication service with applications. Because IM is real-time it is claimed that it can provide relief to call centers if integrated into help applications, or it can serve as real-time communication between apps. Presence also provides opportunity as an application service; in this case it is abstracted to mean any status that changes over time. The advantage is the push nature of updating presence at the distant client.

This has several components:

Using IM for people to communicate with apps

This places an application behind an IM screen name, that the customer communicates with via text, either using natural language, commands, or menu prompts ("Enter 1 for General, 2 for Engineering," etc). The IBM rep put it best--the normal interface would have be pretty bad to make this attractive. It is not far removed from text role playing games or negotiating the Internet from a Unix prompt--no one is going the pass the Turing test. Because text is so light on bandwidth, though, this type of app communication may be ideal for mobile uses.

Using IM for apps to talk to apps

This was the talk of an afternoon session, and to be honest it sounded like an hour of catch phrases. "Every enterprise application has a component that would benefit from real-time interaction"--this point was raised over and over again. The key seemed to be the push update nature of IM--one application could send data as it changed, rather than wait for the other app to request it on a regular schedule. The session was full of off-the-cuff ideas but it seemed that few were selling anything here yet.

Using presence

Presence is just a way of pushing a dynamic state description out to distant users. For people the gradations are from online to offline, with different "away" messages in between. But for applications, presence can be any state change. Examples during the day included stock prices, eBay bid prices, weather, and flight status. In this scenario, the application sits in the buddy list via a screen name, with the presence next to it. For example:

Buddy List


happyguy43 (At Lunch)
studbroker22 (On line)


FlightStatusUAL475 (On time)
StockPriceAOL (12.45)
Weather20817(cloudy 43)

In this buddy list the friends are up top, and the applications include the status of United Flight 475, the stock price of AOL, and the weather in zip code 20817.

Standards and the need for interoperability

Throughout the conference it was clear, particularly from session audience questions, that interoperability of IM solutions is a major issue. Like e-mail and telephone, two revolutionary communications to which IM was compared by several presenters, instant messaging users act like both consumers and employees at the same time. The full impact of IM cannot be achieved while it is so difficult for consumer networks to communicate with enterprise systems, and for different enterprise systems to interoperate with each other.

The technological and business model sticking point is presence. Unlike e-mail and the telephone, presence requires a persistent connectivity between all clients and servers, to ensure that presence status updates can be pushed out as needed. Technologically, this means that for ubiquitous presence, all clients and servers must be able to talk to each other. And from a business model perspective, there is little incentive to interoperate when there is no foreseeable ROI on the effort to do so.

For clients and servers to talk to each other, there must be standards for the communication protocols. At the IETF currently, there are two approaches to IM standards: XMPP (Jabber) and SIP/SIMPLE. Both are nearing approval. The relative merits of each standard were debated vigorously (and loudly) during a session on Tuesday entitled "SIP, SIMPLE, and Jabber: Where Should You Turn?"

Jabber, known by its protocol name XMPP at the IETF, is an open-source initiative to provide a standard protocol to produce IM servers and clients that can interoperate. Like Linux, it is distributed under the General Product License and its source code is available for download. Like Linux, there are several commercial vendors devoted to developing products based on the standard, one of whom, Jabber Inc, was present at the conference. Frank Cardello estimated that there were between 6 and 9 other commercial implementations of Jabber.

Jabber is designed as a protocol for "traditional" IM--the buddy list/conversation window paradigm. And, as an open source initiative, it has several member foundations outside of the IETF whose purpose is the document and administer extensions to the protocol. As a result, several of the panel members described Jabber as a "mature" protocol--there are numerous mechanisms in place to ensure total interoperability between clients and servers. But, there are problems with the protocol: it creates a persistently open TCP port, which limits its ability to work in a mobile environment, and it has very little vendor support.

SIP, the session initiation protocol, is also at the IETF, and is also expected to be approved soon. SIP is not an IM standard, but rather is a protocol for establishing media sessions between two endpoints on a network. Like Jabber it is extensible, but unlike Jabber it is not an open source movement, and therefore extensions to SIP are not published as they are developed. The result is that it is entirely possible that two implementations of SIP could be IETF standard compliant, and yet still not interoperate. For this reason, SIP was called an "immature" protocol by several of the panel members. And although Jonathon Rosenberg, CTO of dynamic soft and author of much of SIP, did an excellent job addressing many of the issues, it did not change the fact that IBM and Microsoft SIP servers cannot interoperate.

An interesting point with SIP is that is does not specify a payload, it simply establishes and manages a connection. Therefore, it can be used for voice, video, or IM. The full SIP IM implementation by Microsoft and IBM is SIP/SIMPLE--SIP with a payload of SIMPLE (Session Initiation protocol for Instant Messaging and Presence Leveraging Extensions). SIMPLE is also at the IETF for standard approval, as part of the SIP working group. But as Maxima Seguineau, CEO of Antepo, stated, XMPP could just as easily be the IM protocol carried by SIP. Antepo is currently researching this standards juxtaposition.

SIP/SIMPLE stands today in a much stronger market position than Jabber (XMPP), simply because SIP/SIMPLE is supported and implemented by Microsoft, IBM/Lotus, and AOL, at least in their 3rd party gateway. Between them MS and Lotus own about 90% of existing enterprise IM servers deployed today, and both are built on, and pushing SIP/SIMPLE hard. Zion Software (see below) stated that they are watching the standards efforts, including IMPP, SIP/SIMPLE, and Jabber. But, they acknowledged, if MS and IBM/Lotus can actually agree on a standard implementation, it will take over, as with SOAP for Web services.

Technological issues are only part of the interoperability picture. Until there are business incentives to provide interoperability, it is unlikely to occur. To IBM, focused squarely on the enterprise market with Lotus Sametime, interoperability is a matter of negotiated connections between the IM servers of two businesses. Over time, according to this thinking, if enough servers run SIP/SIMPLE and negotiate interconnectivity, the end result will be similar to e-mail today: independent e-mail servers cooperating over SMTP to deliver e-mail to the correct address.

But for companies like Yahoo, interoperability is a matter of enterprise servers remaining open to the big 3 public IM networks. But, that raises the question of interoperability between those networks--all of whom run on proprietary protocols. As one presenter put it, there is a "gravity" to large public networks. Because the current revenue model centers on advertising, their interest is in growing their proprietary networks as large as possible, at the expense of their competitors.

Clearly interoperability is going to be a panel subject at IM Planet for years to come. Most presenters estimated it would be solved within 5 years, even if they disagreed how that would occur.

Europe vs. the US

On Monday I spoke with a Yahoo rep and an IBM/Lotus Sametime vendor about Europe. Yahoo says--as with most things tech, Europe is about 12 months behind the US. But, we expect that the demand will develop over there soon. Yes, SMS is established but cost structures make it a difficult proposition for IM interaction or replacement. In Europe the sender is charged for each SMS message and Yahoo has neither the billing structure nor desire to provide this money in an enterprise solution.

I asked--in the US, IM adoption is being driven at the grassroots by young people, who got used to IM as students. In Europe students use SMS instead. How will this affect the future growth?

Answer--Who knows?

The IBM/Lotus Sametime vendor was Cobra, who makes IM bots that run on Sametime. They sell worldwide, and reported over 60 resellers for their products in Europe alone. This is significant because they almost always are sold as an accessory to Sametime installs. So, this represents over 60 Sametime installers/resellers. But beyond this I could only get the vaguest statement that IM is hot in Europe too.

Tuesday was far more fruitful, as the Mobile Messaging Track sessions could not avoid the obvious differences in the US and European mobile markets. In Europe, SMS is king:

SMS represents 15% - 20% of operator revenues.
45% of the European population uses SMS.
People surveyed by Jupiter Research use SMS instead of voice 43% of the time.
SMS is incorporated into some enterprise solutions.

Some IM vendors such as Antepo have therefore tried to bring IM to Europe on phones, over the SMS signal. Like other vendors, Antepo's goal was to recreate the desktop experience by placing a separate IM application on the phone. Yet, users did not take to the additional menus and complications, and in the end SMS use continued to grow, while IM use stayed at around a 1:1000 ratio to SMS use. Even SMS games were used 10 times as often as IM. Don Bergal, VP North America of Antepo, stated that (with the carrier's help), Antepo came to the conclusion that users did not want IM over SMS; they just wanted SMS. He suggested a better solution would be for the carrier to provide an IM/SMS gateway, where server and IM protocols would reside and interact with SMS on the phone. But it was not clear that Antepo was working on this currently.

Frank Cardello, VP of Business Development at Jabber Inc. (an IM server provider), spoke briefly about his company's work with companies such as Antepo, France Telecom, Bell South, and AT&T to interconnect IM with SMS. The success was "spotty at best." In Europe, SMS has taken off, but in his words "there are not a lot of communities built around wired IM that people want to attach to." In the US they faced the opposite problem, that IM is well established but few people use SMS. In short, they and others have not had a lot of success trying to bridge the networks.

The communications cultures of SMS in Europe and IM in the US are mirrors of each other, and the problem that interconnectors face is the same--one network has experienced widespread adoption and the other is barely noticed. This was illustrated by some online ad revenue statistics provided by Michael Gartenberg, Research Director for Jupiter Research:

Wired online ad revenues

US - $6.2 billion
Europe - $1.4 billion

Wireless online ad revenues

US - $0.1 billion
Europe - $2.5 billion

Frank Cardello pointed out that in Europe, for many users the experience of the Internet is based on a phone, while in the US the Internet experience is linked to the keyboard/video/mouse interface. SMS is beginning to appear in enterprise applications in Europe, after a groundswell of popular consumer adoption--just like IM in the US.

WAVE Comments

The great unanswered question remains--what do these dynamics mean for the development of enterprise IM solutions in the European market? Based on what we observed at the conference, an IM solution that succeeds in Europe will have the following attributes:

Seamless integration with SMS

SMS is the established king of instant text messaging in Europe, and IM solutions cannot ignore that.

Rolled out by IT department

Unlike the US, where 84% of companies report grass-roots IM usage, an enterprise IM solution in Europe is much more likely to be a top-down deployment by the IT department.

Simple interface

Europeans are used to real-time text messaging through the simple SMS interface. They may not be as tolerant of complex interfaces as the US.

Internal server

Because there are no huge established IM communities, there is little reason for a company to contract with a public IM provider such as Yahoo for their enterprise solution. IM may be more important as one piece of an internal RTC solution, than for communicating with partners or vendors.

On the Floor

The expo floor is tiny, 14 booths arranged around dining and food tables in a hotel ball room. The entire show has a very small feel to it, and most people seem to know each other. As the complimentary cocktails flowed from 6 to 7pm on Monday, the Yahoo booth unveiled a set of rubber-band-powered foam darts and soon half the room was engaged in an all-out foam dart war. It was like 1998 all over again--the survivors of the Internet meltdown reverting to a happier time. If you can't beat a company in the market place at least you could hit the rep from across the room.

Natural language translators

These are servers that sit between the IM server and the application that the IM bot accesses. The natural language servers translate natural language requests into queries that are sent to the application for processing. They may provide natural language translation back to the client, as desired by the host. We spoke with two:

Natural Messaging

This company was presenting with Palm, who just installed them for internal use, to access a Palm database of handset specs. Natural Messaging's solution is based on VoiceXML, a standard for working with natural language and the subject of a working group at the W3C. Although developed initially for spoken natural language, Natural Messaging felt that VoiceXML was ideal for working with text natural language as well. Its primary benefits are:

It is a standard with an active working group.
As XML it is very extensible.
Developers can easily work with it to develop applications.
It can be extended to include spoken natural language in the future.

The demo was on the new Palm Tungsten, which resembles a large Blackberry in form and runs on the AT&T GPRS/GSM network. It will be introduced in 3 weeks and sold through the carrier. The Palm implementation used natural language input with structured output, although they implied they could do natural language output as well. It was running on Sametime, and it was not clear whether that is their specific platform or if it can run on others.

Sprint is also a partner of Natural Messaging, and like Palm they have deployed a N.M. server for internal use and evaluation. Brent Smolinski, Chief Architect at Natural Messaging, expects that following their evaluation, Palm and Sprint will begin to develop customer applications. Natural Messaging is currently seeking more partners, and appears to be in early an early business development stage.


This company also provides a natural language translation server. They claim their service is able to work with both public and private IM--agnostic. This can provide both natural language translation of input, as well as natural output, configurable by the user. While their primary customer targets are application developers in the HR and customer service space, they have developed several demonstration applications that have proven popular in beta tests.

Zion Software

They have been in business since 1992, and working in the IM space since 1999. Their enterprise IM solutions include both integration with the public networks, and a proprietary protocol IM server, living in both worlds of the dynamic noted above. Their products include:


This is a Java-based universal IM client, that can interact with both IM servers such as Sametime or Zion's JMessageServer, as well as AOL, ICQ, Yahoo, and MSN. It runs on all Java 2 Standard-enable desktops. This client is given away ("nobody pays for the client").


This is an enterprise IM server based on a proprietary protocol. Zion is interested in the standards proceedings taking place, but until there is a clear winner they decided their own protocol would be most robust. The server includes all standard enterprise IM features and uses the JSuperChat client.


This is an SDK to allow application developers to hook into one or many of the "Big 4" IM networks easily. It is available as JBuddySDK for Java developers, or JBuddy.NET for Windows developers.

Zion sell direct right now, although they are trying to develop relationships with VARs, integrators, and consultants. They stated that many have a license and are setting up reference designs now.


This is another company that provides an enterprise IM solution based on a server and client running a proprietary protocol. Its product line is called the Professional Online Desktop (POD) and provides the usual set of monitoring, logging, and security features. It can also provide interoperability with both the Big 3 public networks, and with SIP/SIMPLE, through a gateways on its server.

Cobra Technologies

This software companies creates IM interaction bots for Lotus Sametime, to allow people to interact with Lotus applications via IM. They provide a stable of pre-built, customizable bots, and can develop custom jobs as well (for those who will pay). The bots use prompting, such as "please enter a name," to get around the need for natural language translation. Presence is either online or offline. Pre-built bots include:

Calendar Bot -- view other's calendars
Mail Monitor Bot -- know when you get mail
Directory Bot -- look up contact info
Reminder Bot -- set a reminder for yourself
Lookup Bot -- interact with a Notes database

Cobra is both a developer of the bots, and a Lotus installer and service provider. They sell the bots primarily as accessories to a Sametime sale, either by themselves, working with IBM/Lotus, or through VARs, particularly overseas. They claim over 60 VARs in Europe.

Motorola - Lexicus Division

Why was Motorola at an IM conference? Because they make an IM client. Available in either a Java or embedded version, their IM client resides on a cell phone and uses SMS for the transport. The key difference between IM over SMS and SMS is presence--which is available in the IM browser.

Lexicus Division sells to phone manufacturers, who contract with carriers. The presence and IM connectivity is provided by the carriers. Charging for the service is up to the carriers, with both bucket and single-use plans mentioned. The browser was developed as part of Motorola's membership in the Wireless Village standards project, so it should be interoperable between carriers, including presence. Like all interoperability it is a business question primarily, and it was unclear if anyone was interoperating.

There were no phone manufacturers at IM Planet--so why is Motorola there? Because Jupiter asked them too. They came to the first IM Planet in San Francisco and agreed to come to this one too. "We're the only major cell phone maker in North America, and we are here to provide a mobile point of view."