For Instant Messaging and Presence Services Federation and Standards are Complementary (2005)

In an earlier post to this Blog, my colleague David Via opined that recent announcements by AOL, etc. of the federation of various Instant Messaging and Presence services and offerings reflected a failure of Instant Messaging and Presence standards. I disagree.

I have written a longer piece entitled  "An Introduction to Presence Models and Standards" for the Ferris Analyzer Service. This will be published  in the next couple of weeks.

I will merely summarize some of its content here.

Nick Shelness - Senior Analyst

Standardization

The Internet Engineering Task Force (IETF) has been the main vehicle for the standardization of instant messaging and presence protocols. Unfortunately, this effort has been fraught with  considerable difficulty.

While the IETF's Instant Messaging and Presence Protocol (impp) working group was able to reach rough consensus on both a model of, and a set of requirements for,  instant messaging and presence protocols, they could not reach any consensus on a single protocol specification. The problem was an inability to agree upon an underlying transport. There were  three candidates, each with a set of  unwavering supporters. These were:

1. raw TCP/IP,
2. the Blocks Extensible Exchange Protocol (BEEP), which runs atop TCP/IP and others transports, and
3. the Session Initiation Protocol (SIP).

Due to the  impasse this inability to agree introduced, a decision was reached by the Internet Engineering Steering Group (IESG) to allow the development of three separate, though interoperable, protocol specifications by up to three separate working groups. It would then be left to the market to select between them. The impp working group retained the charter of  specifying  common presence and instant messaging payloads for the purpose of interoperability (CPIM).

Though yet another IETF working group was subsequently chartered to standardize the open-source Jabber Extensible Messaging and Presence Protocol (XMPP), it would appear that at least in the commercial (as opposed to open-source) Enterprise and Telephony markets, the SIP-based protocol (SIP/SIMPLE) has been selected.  Microsoft's Live Communication Server (LCS) employs SIP/SIMPLE, as does IBM's Lotus Workplace,  and Avaya's, Alcatel's, Mitel's, Siemens' (which is based on LCS)  and Nortel's  instant messaging and presence offerings. IBM's Lotus Sametime though T.120 and H323 based, possesses a SIP/SIMPLE gateway, and the recently announced gateways between Microsoft's LCS 2005 SP1 and the public instant messaging services of AOL, Yahoo!, and MSN are also SIP/SIMPLE based.

So SIP/SIMPLE seems to becoming the instant messaging and presence protocol of choice. That's good news. The bad news is that commercial developments have been racing ahead of the SIP/SIMPLE standardization effort. This in and of itself is not a bad thing, as long as vendors:

1. continue contribute to the standardization effort, and
2. drop their proprietary constructs in favor of standardized constructs as the latter become available.

While I can can certainly cite areas where this has not occurred (for example, Microsoft's behavior with respect to IETF calendering and scheduling protocols), in the SIP/SIMPLE arena this does not appear to be a problem.  Microsoft who implemented an early draft version of the IETF's Presence Information Data Format (PIDF) in LCS 2003, replaced this with standard PIDF in LCS 2005, and Gurdeep Singh Pall the Corporate Vice President  of Microsoft's Real Time,  Communications Business Group, in  response to a direct question from this author, committed to continue to replace proprietary features with standardized ones as they become available.

Relevant RFCs

RFC 2778 - A Model for Instant Messaging and Presence
RFC 2779 - Instant Messaging / Presence Protocol
Requirements
RFC 3863 - Presence Information Data Format (PIDF)
RFC 3856 - A Presence Event Package for the Session Initiation Protocol (SIP)
RFC 3857 - A Watcher Information Event Template-Package for the Session Initiation Protocol
RFC 3858 - An Extensible Markup Language (XML) Based Format for Watcher Information
RFC 3903 - Session Initiation Protocol (SIP) Extension for Event State Publication
RFC 3922 - Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)

Relevant IETF Drafts (note these links die 6 months after a draft is posted)

A Data Model for Presence
A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists
Extensible Markup Language (XML) Formats for Representing Resource Lists
RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF)The Message Session Relay Protocol
Functional Description of Event Notification Filtering
An Extensible Markup Language (XML) Based Format for Event Notification Filtering
Inter-domain Requirements for SIP/SIMPLE

Aggregation and Federation

One of the problems with discussions about instant messaging and presence protocols outwith the standards community as that participants  employ the same word to describe  two different constructs and two different words to describe the same construct. The following is an attempt to  defuse this problem.

Aggregation

Within the IETF's model of instant messaging and presence (see RFC 2778), there are three types of entities: a Watcher, a Presentity and a Presence Service. Each Watcher is represented by a single Watcher User Agent (WUA), and each Presentity (represented by an unique URI such as pres:nick@home.net) is represented by zero or more Presence User Agents (PUAs). The latter point is key. It allows a single Presentity (for example, pres:nick@home.net) to have multiple modes of availability and contact (for example, available and contactable via an instant message at a computer, available and contactable via voice telephony on a cell phone ,  available and contactable via a short (SMS) message on a cell phone, etc.). One of the functions of an IETF- model-compliant Presence Service, is to aggregate Presentity status updates (represented by multiple PIDF documents) received from multiple PUAs into a single aggregate Presentity status (represented by a single PIDF document). Therefore. an IETF- model-compliant protocol such as SIP/SIMPLE, will aggregate Presentity status from a number of different sources (PUAs).

Federation

Federation refers to the linking of one or more IETF- model-compliant Presence Services to form a  super-service. This has two potential forms:

1. Intra-domain federation, and
2. inter-domain federation.

Intra-domain federation, the linking of two different presence services within a single presence domain, is not addressed by any standards activity and remains a major problem, even for a single vendor (see for example, Microsoft's performance problems with the intra-domain federation of multiple LCS 2003 servers. A problem purportedly resolved by LCS 2005). The intra-domain federation of instant messaging and presence servers from different vendors is likely to prove extremely difficult, if not impossible , with one exception -- if a subsidiary presence service  operates as a presence proxy (effectively as a PUA)  to a superior presence service. This is the approach being employed by Alcatel, Mitel, and Siemens to report telephony status to Microsoft's LCS 2005.

Inter-domain federation, the linking of two distinct presence communities,  is relatively straight forward, and is a built in feature of Microsoft's LCS 2005 SP1 both with respect to federating two distinct LCS 2005 communities, and federating a single LCS community with one or more of the public instant messaging and presence services operated by AOL, Yahoo!, and MSN.

Super Aggregation

As described above, IETF presence protocols such as SIP/SIMPLE, already
aggregate PIDFs from multiple PUAs acting on behalf of the same presentity
(identified by the same presence URI such as pres:nick@old-mill.net) into a
single PIDF for that presentity, that is then delivered to WUA/s. What the
model does not address is the additional aggregation of PIDFs for different
presentities (e.g., pres:nick@home.net and pres:nh_Shelness@hotmail.com)
into a single super-aggregated PIDF. This lack of coverage does not preclude a
WUA (see for example, Trillian or the IBM Lotus Sametime clients) from
performing such super-aggregation.

Arguably, the
functionality of presentity lists by SIP/SIMPLE presence services (see Lists
above) could be further extended to super-aggregate PIDFs from multiple
federated presentities each representing the same physical entity into a single
super aggregated PIDF.

Summary

I hope that I have made clear in the above that the Federation of instant messaging and presence communities is being based on standards, and that therefore, federation and standardization are supportive and not opposing forces.