A public message from the Internet Engineering Steering Group announces the approval of five proposed standard IETF Working Drafts from the Instant Messaging and Presence Protocol (IMPP) WG. These documents include Presence Information Data Format (PIDF), Common Profile for Instant Messaging (CPIM), Common Presence and Instant Messaging: Message Format, Address Resolution for Instant Messaging and Presence, and Common Profile for Presence (CPP). Two key RFCs on instant messaging were published by the IMPP WG earlier: A Model for Presence and Instant Messaging (RFC 2778) and Instant Messaging / Presence Protocol Requirements (RFC 2779).

The IMPP WG specifications "form the basis for a mechanism by which multiple distinct Instant Messaging applications may pass messages among the different systems while retaining the ability to use end-to-end encryption, integrity protection, and a shared framework for presence information. The work on PIDF (Presence Information Data Format) is already in widespread usage by the SIP-based instant messaging community, as is the message format described."

The IMPP working group, now in the process of concluding its work program, is one of three IETF working groups chartered to develop architectural, protocol, and data format specifications supporting internet-scale end-user presence awareness, notification, and instant messaging systems. The IETF Extensible Messaging and Presence Protocol (XMPP) WG is extending current XMPP protocols "to provide finished support for RFC 2779-compliant security mechanisms, including authentication, privacy, access control and end-to-end as well as hop-by-hop message security. XMPP is an open, XML-based protocol for near real-time extensible messaging and presence and is the core protocol of the Jabber Instant Messaging and Presence technology." The SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) WG has produced a number of SIP-related specifications in parallel with the IMPP WG efforts.

IETF Messaging Working Groups

Working Groups of the IETF Applications Area producing specifications for Instant Messaging and Presence include:

• Instant Messaging and Presence Protocol (IMPP)
• SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)
• Extensible Messaging and Presence Protocol (XMPP)

Bibliographic Information and Overview

• Presence Information Data Format (PIDF). By Hiroyasu Sugano (Fujitsu Laboratories Ltd), Shingo Fujimoto (Fujitsu Laboratories Ltd), Graham Klyne (Nine by Nine), Adrian Bateman (VisionTech Limited), Wayne Carr (Intel Corporation), Jon Peterson (NeuStar, Inc). IETF Network Working Group, Internet Draft. Reference: 'draft-ietf-impp-cpim-pidf-08.txt'. May 2003, expires November 2003. 27 pages.

  "The Common Profiles for Instant Messaging (CPIM) and Presence (CPP) specifications define a set of operations and parameters to achieve interoperability between different Instant Messaging and Presence protocols which meet Instant Messaging / Presence Protocol Requirements (RFC 2779)."

  "This memo further defines the Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant presence protocols, allowing presence information to be transferred across CPP-compliant protocol boundaries without modification, with attendant benefits for security and performance. It also defines a new media type 'application/pidf+xml' to represent the XML MIME entity for PIDF."

  "The format specified in this memo defines the base presence format and extensibility required by RFC 2779. It defines a minimal set of presence status values defined by the IMPP Model document A Model for Presence and Instant Messaging (RFC 2778). However, a presence application is able to define its own status values using the extensibility framework provided by this memo. Defining such extended status values is beyond the scope of this memo. Note also that this memo defines only the format for a presence data payload and the extensibility framework for it. How the presence data is transferred within a specific protocol frame would be defined separately in a protocol specification."

  Section 4 'XML-encoded Presence Data Format' "defines an XML-encoded presence information data format (PIDF) for use with CPP compliant systems. A presence payload in this format is expected to be produced by the PRESENTITY (the source of the PRESENCE INFORMATION) and transported to the WATCHERS by the presence servers or gateways without any interpretation or modification. A PIDF object is a well formed XML document. It must have the XML declaration and it should contain an encoding declaration in the XML declaration, e.g., <?xml version='1.0' encoding='UTF-8'?>. If the charset parameter of the MIME content type declaration is present and it is different from the encoding declaration, the charset parameter takes precedence. Every application conformant to this specification MUST accept the UTF-8 character encoding to ensure the minimal interoperability."

  XML Encoding Decision: "The Presence Information Data Format encodes presence information in XML (eXtensible Markup Language). Regarding the features of PRESENCE INFORMATION discussed above, such that it has a hierarchical structure and it should be fully extensible, XML is considered as the most desirable framework over other candidates such as vCard (vCard MIME Directory Profile, RFC 2426)."

• Address Resolution for Instant Messaging and Presence. By Jon Peterson (NeuStar, Inc). IMPP WG, Internet Draft. September 2003. Reference: 'draft-ietf-impp-srv-04'. 8 pages

  "Presence and instant messaging are defined in RFC 2778. The Common Profiles for Presence (CPP) and Instant Messaging (CPIM) define two URI schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides rules for locating the resources associated with URIs that employ these schemes via the Domain Name Service. These rules could no doubt be applied to the resolution of other URI schemes that are unrelated to instant messaging and presence.

  CPIM and CPP both specify operations that have 'source' and 'destination' attributes. While only the semantics, not the syntax, of these attributes are defined by CPIM and CPP, many instant messaging and presence protocols today support the use of URIs to reflect the source and destination of their operations. The 'im' and 'pres' URI schemes allow such protocols to express the identities of the principals associated with a protocol exchange. When these operations pass through a CPIM or CPP gateway, these URIs could be relayed without modification, which has a number of desirable properties for the purposes of interoperability.

  These URI schemes are also useful in cases where no CPIM/CPP gatewaying will occur. If a particular principal's endpoint supports multiple instant messaging applications, for example, then a domain that identifies that host might use the sort of DNS records described in this document in order to provide greater compatibility with clients that support only one instant messaging protocol. A client would look up the record corresponding to the supported protocol, and learn how to contact the endpoint for that protocol. The principal in this instance would use an IM URI as their canonical address..."

• Common Profile for Presence (CPP). By Jon Peterson (NeuStar, Inc). IMPP WG, Internet Draft. Reference: 'draft-ietf-impp-pres-04'. August 14, 2003. 15 pages.

  Presence is defined in RFC 2778. At the time this document was written, numerous presence protocols are in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines semantics and data formats for common services of presence to facilitate the creation of gateways between presence services: a common profile for presence (CPP).

  Service behavior is described abstractly in terms of operations invoked between the consumer and provider of a service. Accordingly, each presence service must specify how this behavior is mapped onto its own protocol interactions. The choice of strategy is a local matter, providing that there is a clear relation between the abstract behaviors of the service (as specified in this memo) and how it is faithfully realized by a particular presence service. For example, one strategy might transmit presence information as key/value pairs, another might use a compact binary representation, and a third might use nested containers.

  The parameters for each operation are defined using an abstract syntax. Although the syntax specifies the range of possible data values, each presence service must specify how well-formed instances of the abstract representation are encoded as a concrete series of bits.

  In order to provide a means for the preservation of end-to-end features (especially security) to pass through presence interoperability gateways, this specification also provides recommendations for presence document formats that could be employed by presence protocols..."

• Common Profile for Instant Messaging (CPIM). By Jon Peterson (NeuStar, Inc). IMPP WG, Internet Draft. Reference: 'draft-ietf-impp-im-04'. August 14, 2003. 13 pages.

  This specification defines semantics and data formats for common services of instant messaging to facilitate the creation of gateways between instant messaging services: a common profile for instant messaging (CPIM).

  The term 'gateway' used in this draft denotes a network element responsible for interworking between diverse instant messaging protocols. Although the instant messaging protocols themselves are diverse, under the model used in this document these protocols can carry a common payload that is relayed by the gateway. Whether these interworking intermediaries should be called 'gateways' or 'relays' is therefore somewhat debatable; for the purposes of this document, they are called 'CPIM gateways'.

  The term 'instant messaging service' also derives from RFC2778, but its meaning changes slightly due to the existence of gateways in the CPIM model. When a client sends an operation to an instant messaging service, that service might either be an endpoint or an intermediary such as a CPIM gateway -- in fact, the client should not have to be aware which it is addressing, as responses from either will appear the same.

  This document defines operations and attributes of an abstract instant messaging protocol. In order for a compliant protocol to interface with an instant messaging gateway, it must support all of the operations described in this document (i.e., the instant messaging protocol must have some message or capability that provides the function described by each of the given operations). Similarly, the attributes defined for these operations must correspond to information available in the instant messaging protocol in order for the protocol to interface with gateways defined by this specification. Note that these attributes provide only the minimum possible information that needs to be specified for interoperability - the functions in an instant messaging protocol that correspond to the operations described in this document can contain additional information that will not be mapped by CPIM..."

• Common Presence and Instant Messaging: Message Format. By Derek Atkins (IHTFP Consulting) and Graham Klyne (Nine by Nine). Reference: 'draft-ietf-impp-cpim-msgfmt-08.txt'. IETF Network Working Group, Internet Draft. January 09, 2003. 30 pages. See the IESG notification for corrections in Section 3.6 and 4.5.

  "This memo defines the mime content-type 'Message/CPIM'. This is a common message format for CPIM-compliant messaging protocols. While being prepared for CPIM, this format is quite general and may be reused by other applications with similar requirements. Application specifications that adopt this as a base format should answer the questions raised in section 6 of this document.

  The Common Profile for Instant Messaging (CPIM) specification defines a number of operations to be supported and criteria to be satisfied for interworking diverse instant messaging protocols. The intent is to allow a variety of different protocols interworking through gateways to support cross-protocol messaging that meets the requirements of RFC 2779.

  To adequately meet the security requirements of RFC 2779, a common message format is needed so that end-to-end signatures and encryption may be applied. This document describes a common canonical message format that must be used by any CPIM-compliant message transfer protocol, and over which signatures are calculated for end-to-end security..".

• Instant Messaging / Presence Protocol Requirements. By Mark Day (SightPath, Inc), Sonu Aggarwal (Microsoft Corporation), Gordon Mohr, and Jesse Vincent (Into Networks, Inc). IETF Network Working Group, Request for Comments: 2779. Category: Informational. February 2000. 26 pages.

  Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.

  Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.

• A Model for Presence and Instant Messaging. By Mark Day (SightPath, Inc), Jonathan Rosenberg (dynamicsoft), and Hiroyasu Sugano (Fujitsu Laboratories Ltd). IETF Network Working Group, Request for Comments: 2778. Category: Informational. February 2000. 17 pages.

  This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging.

From the IESG Announcement: Working Group Summary

"The IMPP working group was originally chartered to develop requirements and then protocols which would provide an 'Internet-scale end-user presence awareness, notification and instant messaging system'. The group delivered RFCs 2778 and 2779 defining a model and requirements for instant messaging, but it was unable to select among the candidate protocols for this task even after setting up a nine-member design and review team. After this impasse was reached, the work of development was split to allow for multiple, interoperable transport protocols..."

"The IESG has, through [its] review, concluded that the work plan described by the chairs was on target and has conducted their technical review of the documents solely on the question of whether the documents meet the need outlined by that plan..."

In its technical evaluation, the IESG noted that many of the formats and discovery mechanisms described are already in use or replicate well-known existing mechanism. They reflect that maturity in their description and completeness. The core document on CPIM, in contrast, represents a fairl abstract description of the service. The IESG believes that the documents ar of sufficient quality to be the basis of an interoperable service, but notes that it expects the development of documents mapping CPIM to specific protocols to show how to make the abstract terms in CPIM concrete. Further, it expects that interoperability reports presented for the transition to draft standard woul include multiple protocols, as well as the usual requirement that the implementations be independent..."

About the Internet Engineering Steering Group (IESG)

"The IESG is responsible for technical management of IETF activities and the Internet standards process. As part of the ISOC, it administers the process according to the rules and procedures which have been ratified by the ISOC Trustees. The IESG is directly responsible for the actions associated with entry into and movement along the Internet 'standards track,' including final approval of specifications as Internet Standards..."

See the Glossary document for description of the Internet Engineering Task Force (IETF), Internet Architecture Board (IAB), Internet Engineering Steering Group (IESG), The Internet Society (ISOC), and Internet Assigned Numbers Authority (IANA).