continued....
--------------------------------
STANDARDS AND INDUSTRY FORUMS
--------------------------------
Efforts have been ongoing for months to develop standard Instant
Messaging and Presence protocols in the IETF IMPP working group, and
Novell, Lucent and pulver.com have started working with industry
participants to develop the Presence and Availability Management API.
Both of these efforts are in "early days" stages, and so there's been no
liaison or coordination between them at this point. Both the IMPP
workgroup and the PAM specification have provided a set of definitions,
but even these have not been compared or rationalized. This might be a
good first step for any future liaison.
------------------------------------------------------------------------
PAM FORUM SPECIFICATION REVIEW IN BOSTON
------------------------------------------------------------------------
pulver.com, Novell and Lucent held the first PAM (Presence and
Availability Management) Specification Review meeting in Boston on July
16th. The following are my views of events and discussions during the
meeting, and some thoughts about how PAM fits in to the Presence and
Instant Messaging industry.
Lucent and Novell have collaborated on the initial development of the
Presence and Availability Management API specification, and will
contribute the next version of the specification to a new organization
called the PAM Forum. Pulver.com intends to sponsor the PAM Forum as
part of pulver.com and Technical Marketing efforts to build a Presence
and Instant Messaging Community. Steve Holbrook and Lynn Brough
represented Novell at this meeting, and Guda Venkatesh represented Lucent
(more on how to contact Steve and Guda through the Pam Forum web site
later).
Attendees included representatives from Bridgewater Systems, Comverse,
CuseeMe Networks, Evolving Systems, iDap Ltd, Lucent, MeetU.com, Mitel,
MobileOne, Nortel Networks, Novell, Perceptive Networks, SurfandCall
Network Services (a VocalTec company), TeleCommunications Services,
Telefonica Data, TrulyGlobal Inc. (another VocalTec company!), and Tundo
Communications and Telephony.
Lucent and Novell designed the PAM spec to facilitate interoperability
across networks and services, and after receiving industry input, would
like to have the spec become an ad hoc or formal industry standard. The
goal of the PAM spec is to abstract presence to a single API, shielding
developers from the multiple protocols and networks potentially involved.
The specification was also designed to address a perceived shortcoming in
current presence management systems: if a subscriber is "present" he is
assumed to be available. Currently, presence indicates a communications
device is turned on. So, your buddy list may indicate that you are
present when you are online, and your mobile network indicates that you
are present when your phone is turned on. In fact, a subscriber has a
set of preferences, which may specify he wants to be available only to
certain callers, and only via certain devices or networks. In the PAM
API world, availability is equal to presence plus this set of
preferences.
There seemed to be basic agreement among meeting participants that
Presence information will enable most services in the future. Some form
of presence already enables current services such as mobile or wireless
Location-Based Services, and Instant Messaging. PAM capabilities could
be introduced at least three ways:
- PAM abstraction layer on top of legacy systems
- Use PAM API to expose presence info in existing presence-based services
- Add a PAM server as part of "next gen" architecture.
Comments and questions centered around Intellectual Property Rights
(IPR), the scope of the specification, and relation to other protocols,
specifications and organizations. Guda, Steve and Lynn pledged to donate
the specification to the PAM Forum in accordance with the IPR policy to
be established by the independent Forum.
The discussion of the scope of the specification was wide-ranging and
required extra caffeine. Discussion included:
- what should be implementation specific vs. part of the spec
- security (identity authentication and encryption are out of the scope
of the current spec)
- whether the API spec should be mapped to protocols
- what is covered by SIP
- whether the PAM specification should initially address a single
administrative domain.
While the PAM specification is intended to interwork with emerging mobile
network standards and IM protocols, it is not clear from the current
specification document how this would work. This may be something the PAM
Forum looks at in the future. Relationship to other organizations,
particularly the IETF's IMPP working group is another future topic. From
a PAM perspective, the IMPP working group's dual focus on IM and Presence
has led to the "dumbing down" of Presence management capabilities to keep
IM protocols simple (more on this under the Question of the Month).
Another hot topic is providing the end user or "callee" control of
information and how he is communicated with.
The group agreed that Lucent, Novell and pulver.com should formally set
up a new Forum (the PAM Forum), which will own the specification. A
formal IPR policy should be published. As soon as these items are
completed, the industry can provide formal written comments on the
specification. To discourage "lurkers", initial PAM Forum membership may
be limited to companies/individuals providing substantive input.
Lucent and Novell ended up with a large to-do list to move the
specification towards Version 1.0, which they will contribute to the PAM
Forum. It was agreed that a diagram to accompany definitions,
particularly those of agents vs. identities, will be provided by Lucent
and Novell. Also, a definition of capability will be added, and some sort
of reference architecture will be provided. A set of "use cases" was also
suggested to understand the PAM specification from a business perspective.
It was in preparing for this meeting and summarizing Intelligent Network
Forum member comments on the PAM spec that I realized how complex services
delivery across multiple networks and technologies is getting to be.
This spec is a great start at addressing interoperability as well as
developer needs for abstraction. There is a MASSIVE amount of work to be
done to achieve even high level interoperability with existing and future
mobile and IM networks, and to map this API spec to various protocols or
implementations. A good first step would be to attempt to sync up PAM
definitions with those of the IMPP working group.
This detailed services delivery work isn't glamorous, and doesn't attract
a "religious" following, but it has to be done. With so much industry
pressure to deliver solutions quickly, industry participants tend to want
organizations to provide one simple, quick answer to interoperability.
The PAM Forum's next step after delivering version 1.0 of the
specification should be to prioritize the large amount of work to be
done, and to begin building liaisons with related industry organizations.
Want more information? Check out www.pamforum.org, where Novell and
Lucent have posted the current version of the specification. General
information and background information is available, and there is a
feedback button for comments and questions. This feedback button is the
best way to reach Guda and Steve.
----------------------------------------------------
THE IETF'S IMPP WORKING GROUP
----------------------------------------------------
The Instant Messaging and Presence Protocol (IMPP) working group has as
its goal to "develop an architecture for simple instant messaging and
presence awareness/notification...[and] specify how authentication,
message integrity, encryption and access control are integrated." The
working group had not made significant progress by the IETF meeting in
Adelaide this spring. Frustrated by this lack of progress, the IESG
(Internet Engineering Steering Group) took the unusual step of shutting
down working group efforts and asking for separate proposals from
industry players. The concept was that the working group chairs would
pick out the best parts of these proposals and direct the workgroup to
consolidate them into one recommendation.
A model was provided by Fujitsu, dynamicsoft, and Lotus, with the goal of
providing a common vocabulary for these proposals. The model defines
presence and IM as separate services, and contemplates separate protocols
for each.
Two types of clients are defined for presence: presentities (which
provide presence info) and watchers (which receive presence info). Two
types of clients are also defined for instant messaging: senders and
instant inboxes. Senders provide messages; the instant inbox receives the
message. Of course, a presence protocol carries presence information
between presentities and watchers, and an IM protocol carries instant
messages between senders and instant inboxes. The model also specifies
the type of data found in presence systems and provides a set of
definitions. The model is available at
www.http://www.ietf.org/rfc/rfc2778.txt.
A separate RFC (http://www.ietf.org/rfc/rfc2779.txt) specifies shared IM
and presence requirements, as well as requirements specific to IM and
presence and security considerations.
I've waded through the nine submissions that were made to the working
group in mid-June, and made some observations from an industry analyst
point of view (not a technical evaluation!). My thanks to Ben Ziskind of
Bantu and Jonathan Rosenberg of dynamics oft for their assistance with
this section.
The first thing I noticed is that not all of the submissions address
multiple domains or service providers. This seems odd, because the lack
of interoperability among service providers is a major obstacle to
industry growth. I also noticed that not all submissions specified
separate protocols for presence and messaging, although the requirements
are somewhat different.
Also striking was the resemblance of many proposals to Wireless
Intelligent Network and GSM (define) concepts. In these proposals, the
home server in the home domain maintains the presence information, and
this is similar to the Home Location Register in mobile networks
maintaining the subscriber profile. If any of these proposals find their
way into an industry standard, this may support interworking of IP-based
presence services with mobile network presence services.
I've made a pass at summarizing these submissions. If you'd like to view
the full submissions, you can access them via
www.imppwg.org/proposals/index.html.
1. Submission from Invisible Worlds, Content Technologies Ltd.,
Brandenburg Consulting
This submission defines the IMXP protocol, and "IMXP Access Service"
which controls the relaying of messages, and "IXMP Presence Service"
which allows applications to communicate with presence servers in
multiple administrative domains. IMXP is specified as a BXXP profile.
2. Submission from Fujitsu
Fujitsu's submission defining Privacy enhanced Presence Protocol
addresses use in a single administrative domain. Unlike other
submissions, Fujitsu's proposes using a single protocol (PePP) for both
Presence and IM. As discussed above, the proposed architecture seems to
resemble the Wireless Intelligent Network/GSM concepts of the home server
in the home domain being where presence information resides. However, it
does not resemble mobile networks in that a client can only communicate
with its home server. The home server communicates with servers in other
domains regarding presence information. The Fujitsu submission notes that
PePP has features to avoid server and connection bottlenecks and to
increase scalability.
3. Greg Hudson (MIT)
The submission from Greg Hudson, Instant Message and Presence Transfer
Protocols, is similar to the Fujitsu proposal in that it has clients
communicating with home domain servers, and servers talking to each
other. Multiple domain responsibilities are beyond scope of this
document. The protocols for Presence (Presence Information Transfer
Protocol or PITP) and Instant Messaging (Instant Message Transfer
Protocol or IMTP) are similar, and described in the same document.
4. Submission from Alexander J. Fanti
This submission specifies a protocol called RSVP-PP, or Real-Time
Messaging Transport Protocol. This protocol is not related to other
protocols with the RSVP names. It appears to me that Mr. Fanti is
addressing both Presence and IM transport with this protocol, and that
he's working on a protocol called RSVP-IMP to address message content.
As with other submission, clients talk only with servers. Server to
server communication is used for presence status updates (using UDP) and
for validation of subscriber permission.
5. dynamicsoft, Columbia University, Cisco, and Microsoft
The submission from dynamicsoft, Columbia, Cisco and Microsoft consists
of several proposals for extensions to SIP to address the requirements
laid out by the RFP. SIP call setup resembles presence, and therefore
SIP addresses many of the requirements for providing presence. SIP
already provides for registration and storage of the communications
state. An extension to SIP, with two new SIP methods, SUBSCRIBE and
NOTIFY, and a new logical entity - the presence agent, meet requirements
for presence.
The submission proposes an extension with a single new method for SIP to
address IM requirements. The similarity between SIP's Session Initiation
concept and IM should make this extension simple.
6. AOL - IMX
The AOL submission addresses interoperability across multiple domains
without actually specifying any protocols. Emphasis is on problems with
security, and with feature sets working across systems. This approach
focuses on the protocol between servers, not the protocol between clients
and servers, which would make authentication difficult. The submission
also describes AOL's intent to develop the IMX (Instant Messaging
eXchange) architecture, which will use Gateways to relay messages in MIME
format between servers. The IMX protocol uses XML for the markup of
messages. No details of the protocol or protocols to be used between
servers is specified.
7. Jabber.org
The Jabber.org proposal is similar to AOL's IMX in that it uses server
gateways to relay communications, and each server handles all
communications for the clients connected to it. Jabber.org proposes use
of its API to provide Presence and IM capabilities. This API is an
abstraction layer using XML. The advantage of this approach is that
developers and clients would only have to understand simple XML data
types for presence and IM, not the underlying complexity of various IM
networks.
8. Network Projects Inc.
This submission (One IM) defines a set of functional modules needed to
provide Presence and IM services. The submission notes that the
connection model described may not be suitable for mobile network, and
speculates that a different set of protocols may be needed for each
device or network. The submission proposes gateways to translate between
protocols.
9. Microsoft
Microsoft submitted a supplemental proposal on the RVP protocol meant to
describe an existing implementation (Microsoft Exchange 2000) of IMPP work.
The working group chairs' recommendations were as follows:
* The protocol should be compatible with SIP, to allow SIP servers to be
presence servers
* The protocol should be able to run on top of a BXXP mesh
* The protocol itself should not be based on SIP or RVP
* The protocol should be based on one of the other seven proposals.
During July, working group members began to discuss the idea of splitting
the working group into two tracks - a SIP group and an IMXP group. The
Area Directors indicated that more than two groups would be acceptable,
and solicited charter proposals and names of working group chairs. The
hope was that this would be organized before the IETF meeting the week of
July 31st in Pittsburgh. Much heated discussion ensued, and the oneIM,
Fujitsu and other proposals agreed to merge. This effort is now referred
to as "Group 2".
In Pittsburgh, the working group designated a task force of nine members
to analyze three different directions: SIP, IMXP and Group 2. The task
force is charged with defining a common set of functions the protocols
need to do, including a common presence format, common naming
infrastructure, and mapping to a simple protocol flow. If these
commonalities can be defined, then gateways could be built to
interconnect networks using the three protocols, hopefully without a huge
loss of information. The task force is also supposed to develop a
statement about why it is not possible to use a single protocol, if that
is its decision.
The task force's report is due August 21st. Ben Ziskind, of Bantu, who
attended the IETF meeting in Pittsburgh says " With regards to what I saw
at the IETF meeting, the SIP and IMXP factions were really going at each
other on philosophical grounds - doing Presence over a Messaging layer or
doing Messaging over a Presence layer."
In the meantime, AT&T, Excite@Home, iCAST, MSN, Odigo, Phone.com,
Prodigy, Tribal Voice and Yahoo! have formed a new coalition called
IMUnified. This appears to be an effort to achieve at least server to
server interoperability for their IM services while the IMPP working
group attempts to come up with one to three standard protocols. I'm not
sure what the IMPP working group would achieve with three protocols and a
gateway that would be better than IMUnified at this point. We'll report
more on this in next month's newsletter, but it looks like IMUnified's
work could become the ad hoc standard for IM interoperability while the
IETF tries to achieve consensus.
-------------------------------------------------
INTERVIEW WITH DYNAMICSOFT'S JONATHAN ROSENBERG
-------------------------------------------------
I had breakfast with Jonathan Rosenberg, Chief Scientist at dynamicsoft,
at the VON Developers Conference in July. Dynamicsoft is developing a
SIP(Session Initiation Protocol)-based applications server that supports
Presence and Instant Messaging in addition to voice, video and other
communications. One of Jonathan's responsibilities is to work within the
IETF's IMPP (Instant Messaging and Presence Protocol) Working Group to
promote SIP-based protocols.
Dynamicsoft sees its target market as the space where IM, presence, and
voice converge. For example, the company is building an instant
conferencing application. With this application, users can go to a web
site and type in a list of the people they want to conference with. The
application will monitor the presence information of these people, then
ring their PSTN phones when everyone is available.
Like other industry players, dynamicsoft will profit as the industry
grows and matures, and Jonathan and others are focusing on the lack of
interoperability among current IM service providers as the major obstacle
to growth. This lack of interoperability is caused by the use of
proprietary protocols, and this is why Jonathan and others are putting so
much effort into the IETF IMPP Working Group, to try to develop industry
standard IM and Presence protocols. Jonathan co-authored the working
group's RFCs "A Model for Presence and Instant Messaging" in an effort to
jump-start workgroup progress.
In case it's not obvious, Jonathan is an advocate of extending SIP to
develop industry standard IM and Presence protocols. He cites several
reasons he thinks SIP should be the protocol of choice:
- SIP is already an IETF standard
- SIP call setup and presence are similar concepts, and a significant
amount of the requirements for presence protocols can be met by existing
versions of SIP
- SIP uses MIME [Multipurpose Internet Mail Extension, an IETF protocol
for transferring multimedia files or objects over TCP/IP networks] , and
can carry IM text as well as presence data
- Simple SIP extensions could easily handle all Presence and IM protocol
requirements
- Network operators and service providers already using SIP would benefit
from being able to reuse existing hardware and software for Presence and
IM services
- SIP simplifies the delivery of services that span voice, video, IM and
presence.
While Jonathan is the first to admit he can't predict the outcome of the
IMPP Working Group's work, he believes the current contentious but
detailed discussions are a healthy way to work towards industry consensus.
----------------------------------------
QUESTION OF THE MONTH
----------------------------------------
Right now, the media spotlight is on Instant Messaging, rather than the
underlying presence capability. In researching IMPP and PAM and related
issues, I could see that the IM protocols proposed to the IETF's IMPP
working group are pretty simple (this could be seen as an advantage or
disadvantage, of course). I noticed that some of the submissions to the
IETF proposed using the same protocol for both Presence and IM (although
the working group seems to be moving away from this approach after the
Pittsburgh meeting of the IETF). I asked some of the experts whether
they thought this focus on IM and the effort to simplify IM protocols
would keep us from taking full advantage of the capabilities of presence
management in the long run.
The good news is that most of our industry experts think I'm wrong! Most
took a pragmatic business-oriented view, and pointed out that the focus
on IM protocols is a good first step. John O'Sullivan, the Director of
Product Marketing at Hotline, agreed that the focus on IM is distracting
the industry from "the larger topic of presence management". In his
view, it's natural "to identify the concept with the application", so the
tendency is to focus on the familiar IM application rather than the
underlying concept of presence. John pointed that this focus on IM is
not necessarily a bad thing. "Most participants would agree that
protocol standardization is desirable and the immediacy of the issue has
provided impetus to find a solution."
Alex Diamandis, VP of Alliance Marketing at Odigo, John Edwards, Chairman
and CEO of I-Link and Randall Warren, President of Blue Rock Ranch all
agreed with John O'Sullivan that the initial focus on IM would not be a
problem. John Edwards noted that the focus on simplifying IM protocols
should be viewed as "a necessary step to promote a wider adoption of the
[IM] technology", but would lead to richer options for presence
management in the long run. Randall Warren added, "Compatibility between
messaging and presence software packages would allow consumers to select
the products based on their capabilities as opposed to the size of the
installed base or what brand their respective contacts are currently using."
Jonathan Rosenberg of dynamicsoft pointed out that his company "has
already proposed the modest extensions to SIP that will provide full
presence support" and that "even simpler extensions to SIP can easily
address the needs for an IM protocol."
Some on our expert panel viewed simplicity as an advantage. Eric Peyton,
founder of Epicware, noted that a simple interface to presence management
would allow the functionality to be used in a "wider array of
applications". "For example," Eric noted, "... with a clean and standard
interface, PM/IM functionality that worked cross protocol could be
integrated into mail clients to know if someone is going to immediately
receive a sent mail or not."
Just as I was beginning to think I was looking for a problem when there
wasn't one, Harry Hakansson, General Manager of Interactive
Communications at Ericsson, weighed in. Harry says "The focus on
simplifying IM Protocols will only slow down the roll out of
new and exciting services." He asked that the industry take advantage of
the existing complete presence management capabilities (which we've seen
in demos of Ericsson's iPulse products) while pushing for interoperability.
Sue Abu-Hakim, President and CEO of AmikaNow!Corporation took a different
approach, suggesting that the industry should focus on delivering "...IM
with existing protocols such as those of wireless that permit SMS (short
message services)." She thinks the industry should focus on bringing
North American mobile networks up to par with those in Europe and Japan,
where she notes end-to-end two way short message services are already
possible.
The comments that made the most sense to me came from Dr. Kjartan
Emilsson, CTO at OZ.COM. Kjartan thinks the "...focus on IM sort of
hides the complexity involved in presence management. If we compare this
to e-mail, then I think at the time everybody wanted interoperability of
e-mail, and when it happened it laid the grounds for its widespread use.
At the same time people began realizing the drawbacks: no security, spam,
and so on. Since then this has been partially addressed by new standards,
better e-mail clients and more careful use of e-mail in general, but we
still live in a world where the vast majority of e-mails are sent
unencrypted between people and there is practically no way to avoid
spamming."
Kjartan continued "...I think that interoperability of IM will lead to
its general use, but as it is linked fundamentally to the notion of
presence, I think that we will quickly realize that if nothing is done on
the presence management side of things, it might become more annoying than
useful. On the other hand, the interface between IM and presence can be
made pretty clean, meaning that changes and improvement of presence
management does not need to affect the use and distribution of IM. So
going for an all out spreading of simple IM is good for the industry, but
we need to make sure that the presence management part of it can be
upgraded rapidly to meet all the foreseeable problems arising from poor
presence management."
I think these comments show a growing industry awareness of the need for
a clean interface between IM and presence, and the need to treat the two
functionalities separately. It appears that the question of how to treat
presence versus IM is emerging as one of the fundamental issues in the
IMPP working group.
------------------------------
BANTU LAUNCHED
------------------------------
Most Presence and IM services available now are client-based applications
for Windows. Over the past few months, I've tried to use IM to
communicate with colleagues behind corporate firewalls, and their IT
departments have balked at allowing them to down load these clients. It
appears to me that IM would be a significant productivity enhancer in
corporate environments and in the industry, and that corporations have
been missing out on a great way to improve communications with their
customers and also among employees.
It appears that Bantu has addressed this problem with its new hosted
service. I talked with Larry Schlang, President and CEO and Dana Theus,
VP of Marketing, as they were preparing for the August 1st launch of
Bantu Messenger, a hosted IM solution. Bantu Messenger is the flagship
service of the new company, and it provides Instant Messaging and
Presence, with a chat component. Because Bantu is a hosted solution and
the entire application resides on Bantu servers, users can access their
Bantu service from any web device, and there is no client software to
download. This should make the service very attractive to corporate users
and their IT departments.
The advantages of a hosted solution are the lack of overhead for IT
departments and the ability to access the service through any platform or
appliance that has web access. As with other hosted services, solutions
are easy to implement, and are updated by the host/outsourcing company.
I understood how this "thin client" solution addressed the problem of IT
department objections, but then what about getting a message through
corporate firewalls? Bantu messages look like http web pages, which the
Bantu team says allows Bantu Messenger to work through most firewalls and
proxy servers.
The more I know about presence management, the more I'm interested in
solutions that address privacy concerns. Bantu encrypts message streams
between users, and also offers different levels of privacy protection. A
Bantu subscriber can set his status to invisible, which means other
subscribers can't tell he's online. The subscriber can also set
exceptions to this - he can select people who are allowed to see through
this "cloak of invisibility". There is also an "ignore" list - a list of
people the subscriber does not wish to receive messages from!
Bantu Messenger interoperates with ICQ, Yahoo and MSN. Larry IM'ed me on
my Yahoo Messenger account while we were talking, so I can attest to the
Yahoo interoperability. Bantu also supports multilingual web sites,
including Spanish, Portugese, French, Italian, German and English.
I asked Larry and Dana to describe their business model. Bantu is a B2B
provider of Presence and IM, providing instant communications to
corporations, web sites and ISPs. Bantu's revenue stream comes from
usage, subscription or user-based fees from partners such as Lycos Latin
America, OneMain and ILN.net.
If you'd like to check out Bantu Messenger for yourself, go to
www.bantu.com. We'll be watching Bantu to see if this model of hosted
service increases the usage of IM in corporate environments.
-----------------------------
UPCOMING EVENTS
-----------------------------
October 24-25, 2000 - pulver.com's Wireless Internet Summit
New York, NY ( pulver.com )
November 28-30, 2000 - Fall 2000 Presence and Instant Messaging
San Jose, CA (http://pulver.com/im2000 ) |
