IM Planet Spring 2003
by James Sneeringer
Wave Issue 306 3/7/03
February 24 - 25, 2003
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
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
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
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:
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
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.
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
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
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.
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:
happyguy43 (At Lunch)
studbroker22 (On line)
FlightStatusUAL475 (On time)
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
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?
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
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.
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.
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.
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
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:
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
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.
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
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
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
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.
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
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."