[JDEV] (no subject)

Amarnath Yara amarny at hotmail.com
Thu Apr 4 16:46:24 CST 2002


Hi All, Here is an interesting article on IM Interoperablity by Neil 
Sengupta of US Computing, Inc. For details visit 
http://kellster.com/IMinteroperability.asp

Amar

              Instant Messaging – The Hope Of Interoperability
                    Neil Sengupta, US Computing, Inc.

It is very clear that Instant Messaging has emerged as a significantly 
popular option when it comes to Internet Communication technologies. So far 
IM has been brought to the individual consumers by only a few companies – 
AOL, Yahoo, MSN, ICQ etc. It is completely understandable that these 
companies have invested very early in the IM market and therefore feel a 
justified need to protect their consumer base from competitors.  At the same 
time there is a rapidly developing need and interest among the user 
community to be able to IM across multiple vendor platforms. This document 
presents an easy (hopefully) proposal through which other companies could 
offer IM services that are interoperable with the existing popular systems 
and at the same time enable the existing IM services to maintain their 
relationship with the end user. Through out this document the terms 
“established IM vendors”, “established IM platforms” etc. will be used to 
collectively refer to the existing popular IM providers – AOL, ICQ, MSN and 
Yahoo.


Need for Interoperability
>From the IM user perspective there is no denying that interoperability is a 
strongly desired feature. We in the industry want to ensure that consumers 
are well aware of our branding while they use our services. However people 
think in terms of people rather than in terms of Vendors and Systems.

An easy testimonial to this is the fact that people are unwilling to change 
their IM systems since they already have large buddy lists on that system. 
Lack of interoperability keeps them shut away from others in their social 
circle.

If I use a long distance provider A and I have a friend in California that 
uses a log distance provider B – I can still pick up the phone and call my 
buddy. From a consumer’s perspective this should be possible with Instant 
Messaging – just as it is with email. We may use different email providers 
but we can still exchange email.

Past and Ongoing Efforts
There are several ongoing efforts at IM interoperability. However, nearly 
all of them have been met with strong resistance from the established IM 
vendors. This has been primarily due to the need for users to abandon an 
existing established IM client for a client that supports interoperability. 
The established vendor has responded by blocking entry from external clients 
into their servers. This move is understandably motivated by a need for the 
IM vendors to protect themselves from losing their touch-point or desktop 
relationship with the end user.

Majority of the interoperability efforts such as those by Odigo, Trillian 
etc. have been client based. This means that the interoperable client uses a 
client proxy to connect to an external IM platform. As a result the user is 
forced to switch clients if they want interoperability.

An additional issue with interoperability efforts has been has been that 
such clients require users to provide other established IM system login 
names and passwords. Needless to say that this raises concerns on the side 
of the established providers since now their system login information is 
entered by users into a “foreign” application.

The Jabber Organization proposes a server-based interoperability. This 
definitely deserves attention. The Jabber proposal specifies an IM 
user-addressing scheme very similar to Email.

The issue thus far with the Jabber effort has been in getting the 
established IM vendors to buy into Jabber concept. The existing major 
players do not support Jabber compatibility. Jabber gets around this by 
building client proxies (referred to as Transports) which run on the Jabber 
server.  The transport essentially emulates the native protocol of the 
established IM system. So a Jabber client never connects directly to a third 
party IM system. The Jabber client connects to the Jabber server. The Jabber 
server then uses its Transport to connect to an established IM platform.

However none of the existing established IM platforms support Jabber. As a 
result if users want to use a Jabber based system they have to use a Jabber 
compatible client – and none of the established vendors want that to happen 
since they lose their end user relationship. And round and round it goes.

The proposal presented below is based along the lines of server side 
interoperability and “email like” IM addressing schemes, similar to what is 
proposed by the Jabber organization. The proposal also provides solutions to 
work around and resolve the issues that have impeded server-based 
compatibility thus far.

Proposal
A safe compromise is possible if IM providers would agree to a simple 
protocol that would allow users to message across platforms without having 
to leave their current providers IM client.

The idea is that IM would operate very similar to Email when it comes to 
user addressing. For example a Yahoo users IM id could be 
romulus at im.yahoo.com and an AOL users IM id could be remus at im.aol.com. Each 
user would simply use the full address to message each other from the native 
Yahoo and AOL client.

Presence information could be handled by a protocol agreement such that the 
servers would exchange Presence data. If romulus added remus at im.aol.com (and 
remus allows this) to their buddy list then whenever remus logs into the AOL 
IM server the server would notify the Yahoo IM server which in turn would 
send remus’ presence to romulus. Note that romulus would still use the 
native Yahoo client and remus would still use the native AOL client.

This proposal would work if all the vendors decided on a common (perhaps XML 
based) simple protocol through which IM servers can exchange messages.

Vendor Advantage Protection
An IM vendor certainly does not want to lose the advantage they have in 
users that have already adopted their IM clients. This proposal protects 
that advantage.

Each IM vendor’s user community still remains protected. This is because 
each user continues to use the vendor’s proprietary client. The user would 
not need to switch their clients to talk to a buddy on another system since 
the cross platform message and presence exchange is handled server to 
server.

Security Maintenance
Vendor does not have to worry about the user inputting their platform 
specific login name and password into a third party client. This is because 
the cross platform communication would happen server-to-server just like 
email.


User Benefits
Interoperability definitely will increase user delight in many different 
ways. Users no longer will have to leave out communication with their 
Internet friends that use other IM clients. They will also not have to run 
multiple IM vendor clients on their desktop to keep in touch with friends on 
multiple IM buddy lists. The user can have a single IM id instead of 
multiple ids across multiple systems.

Interoperability has been a reality in major forms of communication. Telco’s 
and Email providers permit it. What’s more so do the traditional “snail” 
mail carrier – US post will work with Postal services across the world to 
exchange letters. The time is ripe for IM vendors to do the same.

If you would like to comment on this article please email the author at 
neil.s at uscomputinginc.com
http://www.chatterfish.com










_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx




More information about the JDev mailing list