Presence Document

The following documents are concerned with the XML-based presence and extensions to cover additional information. Key specifications include Presence Information Data Format (PIDF) and RPID - Rich Presence Information Data Format.

• 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. Work product of the IETF Instant Messaging and Presence Protocol Working Group (IMPP). [IETF Source]

  "This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type 'application/pidf+xml' to represent the XML MIME entity for PIDF. 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 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. 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)."

• "Future Presence: Extensions to the Presence Information Data Format." By Henning Schulzrinne (Columbia University, Department of Computer Science). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-future-00'. February 8, 2004, expires August 8, 2004. 13 pages. See the announcement. "The Future Presence extension adds elements to the Presence Information Data Format (PIDF) that allow a presentity to declare their status for a time in the future... Presence information, e.g., represented as PIDF and RPID, describes the current state of the presentity. RPID allows to indicate how long certain aspects of the status have been valid and how long they are expected to be valid, but the time range has to include the time when the presence information is delivered to the watcher... In some cases, the watcher can better plan communications if it knows about the presentity's future plans. For example, if a watcher knows that the presentity is about to travel, it might place a phone call earlier. It is also occasionally useful to represent past information since it may be the only known presence information; it may give watchers an indication of the current status..." [IETF source]

• "User Agent Capability Presence Status Extension." By Mikko Lonnfors and Krisztian Kiss (Nokia). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-prescaps-ext-00'. February 7, 2004, expires August 7, 2004. 28 pages. See the announcement. "Interoperation of Instant Messaging and Presence systems has been defined in IMPP working group. IMPP WG has come up with baseline interoperable operations and formats for presence and instant messaging systems. However, these base formats might need standardized extensions in order to enable building rational applications using presence and instant messaging. This memo proposes an extension to PIDF presence document format to represent "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)" capabilities to be used in SIMPLE based presence systems but may also be applied to other protocols as well." [IETF source]

• "BINPIDF: External Object Extension to Presence Information Data Format." By Mikko Lonnfors, Eva Leppanen, and Hisham Khartabil (Nokia). IETF SIMPLE WG, Internet-Draft. Reference: 'draft-lonnfors-simple-binpidf-00'. April 7, 2003, expires October 6, 2003. "This memo specifies a methodology whereby external content to a presence information document can be referenced in XML encoded presence information document (PIDF). The external content can be either transferred directly in the payload of SIP messages or indirectly as an HTTP reference..." [expired draft]

• "Extensions to the Presence Information Document Format (PIDF) for Conveying Phone State." By Jonathan Rosenberg (dynamicsoft) and Jon Peterson (Neustar). IETF SIMPLE Working Group, Internet Draft. 'draft-rp-simple-pidf-phone-00'. June 23, 2003, expires December 22, 2003. 21 pages. See the announcement. "This document presents extensions to the Presence Information Document Format (PIDF) for representing the state of telephones. This state includes whether the telephone is in a call or not, whether it is registered to the network, whether it is ringing, and so on... While the presence states associated with wireless phones, POTS phones and enterprise PBX phones do vary, there are certain pieces of presence state that are common to all. In particular, the notion of call state is common across all three types. As such, we specify a common XML schema for describing call state." [online source, expired at "http://www.ietf.org/internet-drafts/draft-rosenberg-peterson-simple-pidf-phone-00.txt"]

• "A Presence-based GEOPRIV Location Object Format." By Jon Peterson (NeuStar, Inc). IETF GEOPRIV Working Group, Internet Draft 'draft-peterson-geopriv-pidf-lo-02'. October 27, 2003, expires April 26, 2004. 15 pages. "This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties... A need has been identified to convey geographical location information within an object that includes a user's privacy and disclosure preferences and which is protected by strong cryptographic security. Previous work has observed that this problem bears some resemblance to the general problem of communicating and securing presence information on the Internet. Presence provides a real-time communications disposition for a user, and thus has similar requirements for selective distribution and security. Therefore, this document extends the XML-based Presence Information Data Format (PIDF) to allow the encapsulation of location information within a presence document..." [IETF source]

• "CIPID: Contact Information in Presence Information Data Format." By Henning Schulzrinne (Columbia University). IETF SIMPLE Working Group, Internet Draft. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Reference: 'draft-ietf-simple-cipid-00'. February 8, 2004, expires August 8, 2004. 15 pages. See also the announcement.

  The Contact Information for Presence Information Data Format (CIPID) adds elements to the Presence Information Data Format (PIDF) that provide additional contact information about a presentity and its contacts, including references to address book entries and icons... In its function of facilitating communication, the usefulness of presence information can be enhanced by providing basic information about a presentity or contact. This document describes a basic set of information elements that allow a watcher to retrieve additional information about a presentity or contact. We describe elements for providing a 'business card', references to the homepage and an icon. All can be used either for a presentity or for a tuple (or both)..." [IETF source]

• "SIMPLE Presence Document Usage Examples." By Robert J. Sparks (dynamicsoft). IETF Network Working Group, Internet Draft. Reference: 'draft-sparks-simple-pdoc-usage-00'. October 17, 2003, expires April 16, 2004. 27 pages. "This draft details several use-cases of systems using SIMPLE presence documents. It explores the interaction of systems with different requirements and assumptions." [IETF source]

• "Requirements for SIP Capabilities in PIDF." By Paul Kyzivat (Cisco Systems). IETF SIMPLE Working Group, Internet Draft, 'draft-kyzivat-simple-prescaps-reqts-00.txt'. October 2002, expires April 2003. 7 pages. "This document sets forth requirements for the definition of elements for representation of SIP specific features within the Presence Information Data Format (PIDF), as well as for guidelines on how to use these new elements with PIDF to represent the capabilities of a SIP User Agent Server." [IETF source]

• "RPID - Rich Presence Information Data Format." By Henning Schulzrinne (Columbia University), Vijay Gurbani (Lucent), Paul Kyzivat (Cisco Systems), and Jonathan Rosenberg (dynamicsoft). February 9, 2004, expires August 9, 2004. 24 pages. Section 6 (pages 13-16 ) documents the XML Schema Definitions. Updates version -00. See the announcement.

  "The Rich Presence Information Data Format (RPID) adds elements to the Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. This information can be translated into call routing behavior or be delivered to watchers, for example. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity... This extension does not replace media negotiation mechanisms defined for SIP (e.g., SDP), therefore media negotiation (e.g., choice of voice and video codecs) MUST be performed according to RFC 3264. This extension is only aimed to give the watchers hints about the presentity's preferences, willingness and capabilities to communicate before watchers initiate SIP-based communication with the presentity...

  "... we describe the RPID elements in detail. <activity>, <idle> <placetype>, <privacy>, <relationship>, extend the PIDF <status> element, while <class> and <contacttype> extend the PIDF <tuple> element. In general, it is highly unlikely that a presentity will publish or announce all of these elements at the same time. Rather, these elements were chosen to give the presentity maximum flexibility in deriving this information from existing sources, such as calendaring tools, device activity sensors or location trackers, as well as to manually configure this information..." Earlier: "RPIDS: Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP)", draft-schulzrinne-simple-rpids-02, February 21, 2003, [cache]

• "Identification of Services in RPID (Rich Presence Information Data)." By Adam Roach (dynamicsoft). IETF Network Working Group, Internet Draft. Reference: 'draft-roach-simple-service-features-00'. February 6, 2004, expires August 6, 2004. 13 pages. See the announcement. "This document describes a system by which one can identify certain classes of service using the capabilities published in presence documents. By identifying the probable presence of such services, the chances of a succesful rendezvous are increased... Previous discussions of presence document usage have considered several different views of presence information. In particular, one major open question has been whether to indicate service names explicitly in presence information, or to infer the ability of a user to use a particular service based on the combination of attributes that a presentity publishes in its presence document. The following discussion demonstrates why enumeration of services is undesirable, and proposes that a proper interpretation of capabilities published in presence documents is sufficient for consumers of such documents to deduce the likely presence of particular services..." The document considers services such as Audio Call, Videophone, Whiteboarding, Application Sharing, Instant Messaging, (Page Mode Instant Messaging, Session Mode Instant Messaging), Walkie-talkie, Video walkie-talkie, Voice Instant Messaging, Remote Printer, Email. [IETF source]

Authorization, Authentication, and Policy

Several of the SIMPLE/SIP drafts relate to security and privacy requirements expressed in RFC 2779 and subsequent requirements documents.

• Common Policy. By Henning Schulzrinne (Columbia University, Department of Computer Science), John B. Morris, Jr. (Center for Democracy and Technology), Hannes Tschofenig (Siemens), Jorge R. Cuellar (Siemens), James Polk (Cisco), and Jonathan Rosenberg (DynamicSoft). With contributions from Christian Guenther (Siemens AG). IETF GEOPRIV Workong Group, Internet Draft. Reference: 'draft-ietf-geopriv-common-policy-00'. February 9, 2004, expires August 9, 2004. 36 pages. Section 13 provides the XML Schema Definition. See the announcement. According to a summary by Jonathan Rosenberg, this document represents a first step in 'integrating the GEOPRIV and SIMPLE authorization specifications... 'draft-ietf-geopriv-common-policy-00' is the common policy specification. It outlines the framework for representing policies, and defines some basic elements, such as confirming subscriptions and identifying watchers. At this time, it includes support for the 'exception' clause against domains..." "This document defines a framework for authorization policies controling access to application specific data. This framework combines common location- and SIP-presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains... This framework is the result of finding the common aspects of single authorization systems that more specifically control access to presence ['draft-ietf-simple-xcap-auth-usage-01'] and location information ['draft-ietf-geopriv-policy-00'] and that previously had been developed separately. The benefit of combining these two authorization systems is two-fold. First, it allows to build a system which enhances the value of presences with location information in a natural way and reuses the same underlying authorization mechanism. Second, it encourages a more generic authorization framework with mechanisms for extensibility. The applicability of the framework specified in this document is not limited to policies controling access to presence and location information data, but can be extended to other applications domains. [IETF source]

• "Geopriv Policy." By Henning Schulzrinne (Columbia University, Department of Computer Science), John B. Morris, Jr. (Center for Democracy and Technology), Hannes Tschofenig (Siemens), Jorge R. Cuellar (Siemens), and James Polk (Cisco). IETF GEOPRIV Working Group, Internet Draft, 'draft-ietf-geopriv-policy-01'. February 16, 2004, expires August 16, 2004. 28 pages. "This document defines an authorization policies language for controling access to location-based presence information. This language extends the common policy markup language towards location-specific access control needs... [It] integrates into and extends the framework defined in Common Policy. That document provides an abstract authorization framework for expressing policy rules. As specified there, each such rule consists of a 'conditions', an 'actions', and a 'transformations' part. Conditions determine under which circumstances the LS is permitted to perform 'actions' (e.g., subscription to a service). 'Transformations' implement a mechanism to optionally modify information elements returned to the requestor (e.g., to reduce the granularity of location information). The term 'transformation' is also known as 'provisional action'. The Geopriv policy markup language introduced by the schema in section Section 10 extends the common policy markup language (see Common Policy) by introducing new members of the 'condition' and 'transformation' substitution groups defined there. To express civil location information, it makes use of the schema in section 2.2.3 of 'A Presence-based GEOPRIV Location Object Format' [draft-ietf-geopriv-pidf-lo-01] that defines the 'civilAddress' complex type..." [version -00, "Policy Rules for Disclosure and Modification of Geographic Information"; IETF source]

• "Presence Authorization Rules." By Jonathan Rosenberg (dynamicsoft). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-rosenberg-simple-rules-00'. February 9, 2004, expires August 9, 2004. 20 pages. See the announcement. "Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted." This specification extends Common Policy with presence specific data; in particular, the abstract condition, action, and transformation elements are made concrete. It is intended [pending review] to replace draft-ietf-simple-xcap-auth-usage-01.txt (jr). See updated version referenced below. [IETF source]

• "Presence Authorization Rules." Reference: IETF SIMPLE Working Group, Internet Draft 'draft-ietf-simple-presence-rules-00'. Date: April 30, 2004, expires October 29, 2004. 23 pages. Now an approved Working Group I-D; see the preceding reference.

• "An Extensible Markup Language (XML) Representation for Expressing Policy Capabilities." By Jonathan Rosenberg (dynamicsoft). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-rosenberg-simple-common-policy-caps-00'. February 9, 2004, expires August 9, 2004. 11 pages. See the announcement. "An important component of presence and location services is policy. Policy systems allow the presentity or location target to grant access to specific pieces of information to specific watchers or requestors. These policy systems can be extremely simple, allowing a user to accept or block requests based solely on the identity of the requestor, to extremely complex, allowing for time based rules that grant or deny specific pieces of information. Policy systems often support vendor proprietary features. To allow for interoperability between clients which set such policies, and servers which execute them, it is necessary for clients to be able to determine the capabilities of the server to which it is connected. This specification defines an Extensible Markup Language (XML) based format for expressing such capabilities... When a client, acting as an agent of a PT, starts up, it obtains this document from its policy server. This specification does not prescribe a singular means of transporting such a document between the server and the client. It is anticipated that different systems may use different techniques. However, for systems that make use of the XML Configuration Access Protocol (XCAP), Section 7 defines an application usage that allows for the transfer of the document using XCAP." Note: The "supported permissions" features documented in an early 'xcap-auth-usage' I-D were removed and are now broken into a common core document and a presence specific one: 'draft-rosenberg-simple-common-policy-caps-00' specifies the common document, while 'draft-rosenberg-simple-pres-policy-caps-00' defines capabilities specific to presence. See the note of Jonathan Rosen. [IETF source]

• "An Extensible Markup Language (XML) Representation for Expressing Presence Policy Capabilities." By Jonathan Rosenberg (dynamicsoft). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-rosenberg-simple-pres-policy-caps-00'. February 9, 2004, expires August 9, 2004. 8 pages. See the announcement. "An important component of presence services is policy. Policy systems allow the presentity to grant access to specific pieces of information to specific watchers. To allow for interoperability between clients which set such policies, and servers which execute them, it is necessary for clients to be able to determine the capabilities of the server to which it is connected. This specification defines a set of Extensible Markup Language (XML) elements for expressing presence policy capabilities. "An Extensible Markup Language (XML) Representation for Expressing Policy Capabilities" defines the structure of common policy capability documents. In that specification, each policy capability document has three components: a list of supported conditions, a list of supported actions, and a list of supported transformations. This specification merely extends that document with the conditions, actions and transformations defined in "Presence Authorization Rules." It does so by defining six empty elements -- 'anonymous', 'accept-subscription', 'provide-presence', 'show-namespace', 'show-tuple', 'show-element' -- each of which indicates whether the respective attribute in Policy Capabilities is supported..." Note: The "supported permissions" features documented in an early 'xcap-auth-usage' I-D were removed and are now broken into a common core document and a presence specific one: 'draft-rosenberg-simple-common-policy-caps-00' specifies the common document, while 'draft-rosenberg-simple-pres-policy-caps-00' defines capabilities specific to presence. See the note of Jonathan Rosen. [IETF source]

• "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)." By Jon Peterson (NeuStar). IETF SIP Working Group, Internet Draft. Reference: 'draft-ietf-sip-identity-01'. February 2003, expires August 2, 2003. 16 pages. "The existing mechanisms for expressing identity in the Session Initiation Protocol oftentimes do not permit an administrative domain to verify securely the identity of the originator of a request. This document recommends practices and conventions for authenticating end users, and proposes a way to distribute cryptographically secure authenticated identities within SIP messages." [IETF source]

• "SIP Authenticated Identity Body (AIB) Format." By Jon Peterson (NeuStar). IETF SIP Working Group, Internet Draft. Reference: 'draft-ietf-sip-authid-body-02'. June 28, 2003, expires December 27, 2003. 12 pages. "RFC 3261 introduces the concept of adding an S/MIME body to a SIP request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given." [IETF source]

• "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)." By Jon Peterson (NeuStar, Inc), James M. Polk (Cisco Systems), Douglas C. Sicker (University of Colorado at Boulder), and Hannes Tschofenig (Siemens AG). IETF SIPPING Working Group, Internet Draft. Reference: 'draft-ietf-sipping-trait-authz-00'. February 7, 2004, expires August 7, 2004. 16 pages. "This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol. While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allow greater privacy for users of an identity system." Note: among the constraints and requirements for trait-based authorization in SIP (section 5): "The mechanism MUST have a single baseline mandatory-to-implement authorization assertion scheme. The mechanism MUST also allow support of other assertion schemes, which would be optional to implement. One example of an assertion scheme is SAML." [IETF source]

XCAP Protocol

• [June 15, 2006] The Extensible Markup Language (XML) Configuration Access Protocol (XCAP). Edited by Jonathan Rosenberg (Cisco Systems). IETF SIMPLE Working Group. May 5, 2006, expires November 6, 2006. Versions: see the ID tracker. The IESG received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)" as a Proposed Standard. XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP "maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. In many communications applications, such as Voice over IP, instant messaging, and presence, it is necessary for network servers to access per-user information in the process of servicing a request. This per-user information resides within the network, but is managed by the end user themselves. Its management can be done through a multiplicity of access points, including the web, a wireless handset, or a PC application. This specification describes a protocol that can be used to manipulate this per-user data. XCAP is a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Because of this structure, normal HTTP primitives can be used to manipulate the data. XCAP is based heavily on ideas borrowed from the Application Configuration Access Protocol (ACAP), but it is not an extension of it, nor does it have any dependencies on it. Like ACAP, XCAP is meant to support the configuration needs for a multiplicity of applications, rather than just a single one."

• "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)." By Jonathan Rosenberg (dynamicsoft). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-xcap-02'. February 15, 2004, expires August 15, 2004. 46 pages. See the changes vis-à-vis the version -01 Internet Draft. "This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP is not a new protocol. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP... The specification describes a protocol that can be used to manipulate per-user data. It defines a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Because of this structure, normal HTTP primitives can be used to manipulate the data. XCAP is based heavily on ideas borrowed from the Application Configuration Access Protocol (ACAP), but it is not an extension of it, nor does it have any dependencies on it. Like ACAP, XCAP is meant to support the configuration needs for a multiplicity of applications, rather than just a single one." [source; previous version -01 now obsolete]

• "A Session Initiation Protocol (SIP) Event Package for Modification Events for the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Managed Documents." By Jonathan Rosenberg (dynamicsoft). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-xcap-package-01'. February 16, 2004, expires August 16, 2004. 20 pages. "This specification defines a Session Initiation Protocol (SIP) event package for finding out about changes to documents managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to manipulate XML documents on a server which contain configuration information for application protocols. Multiple clients can potentially access the same document, in which case the other clients would like to be notified of a change in the document made by another. This event package allows a client to do that... This package would be used by any client which is retaining a cached copy of a document obtained by XCAP, so that it can find out when a change has been made, invalidating its cached copy. In fact, the notifications generated by this package indicate the specific change which occurred in the document, so the client can decide whether the change is significant enough to warrant a refetch from the XCAP server..." See also the comment and the previous version -00. [IETF source]

Provisioned Data: Buddy Lists, Default Presence Documents

• "An Extensible Markup Language (XML) Format for Representing Resource Lists." By Jonathan Rosenberg (dynamicsoft). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-xcap-list-usage-02'. February 15, 2004, expires August 15, 2004. 19 pages. See the description of changes from version -01. "In multimedia communications, presence and instant messaging systems, there is a need to represent lists of Uniform Resource Identifiers (URIs). These lists, which typically reside on a server, can be subscribed to, in order to learn the presence status of a group of users. A Session Initiation Protocol (SIP) INVITE message can be sent to them, causing the creation of a conference call. This specification defines an Extensible Markup Language (XML) document format for representing resource lists. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted." [source]

• "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents." By Markus Isomaki (Nokia Research Center) and Eva Leppanen (Nokia). IETF SIMPLE Working Group. Reference: 'draft-isomaki-simple-xcap-pidf-manipulation-usage-00'. February 6, 2004, expires August 6, 2004. 11 pages. See the announcement. Despite the labeling (characterized as a typo) in "draft-isomaki-simple," this specification is actually approved as a SIMPLE WG Internet Draft. [IETF source]

  "This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence document. It is mainly intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs based on which it builds the overall presence state for the presentity."

  "... The Session Initiation Protocol (SIP) for Instant Messaging and Presence (SIMPLE) specifications allow a user, called a watcher, to subscribe to another user, called a presentity, in order to learn their presence information. A SIP based mechanism, SIP PUBLISH method, has been defined for publishing presence state. However, SIP PUBLISH has a limited scope and does not address all the requirements for setting presence state..."

  "XML Configuration Access Protocol (XCAP) allows a client to read, write, and modify application configuration data, stored in XML format on a server. The data has no expiration time, so it must be explicitly inserted and deleted. The protocol allows multiple clients to manipulate the data, provided that they are authorized to do so. XCAP is already used in SIMPLE based presence systems for manipulation of presence lists and presence authorization policies. This makes XCAP an ideal choice for doing device independent presence document manipulation. This document defines an XML Configuration Access Protocol (XCAP) application usage for manipulating the contents of presence document. CPIM PIDF is used as the presence document format, since event state compositor already has to support it, as it is used in SIP PUBLISH. Section 3 [of this specification] describes in more detail how the presence document manipulated with XCAP is related to soft state publishing done with SIP PUBLISH..."

• "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Conference Policy." By Petri Koskelainen and Hisham Khartabil (Nokia). IETF XCON Working Group, Internet Draft. Reference: 'draft-koskelainen-xcon-xcap-cpcp-usage-02'. February 4, 2004, expires August 4, 2004. 31 pages. "This document describes conference policy data elements and the mechanisms to manipulate them at a server via Conference Policy Control Protocol (CPCP). Extensible Markup Language (XML) Configuration Access Protocol (XCAP) is used to implement CPCP. This document specifies an XML Schema and XCAP application usage that are needed to implement CPCP." [IETF source]

Watcher Information

• "An Extensible Markup Language (XML) Based Format for Watcher Information." Edited by Jonathan Rosenberg (dynamicsoft). Internet Engineering Task Force (IETF) SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-winfo-format-04.txt'. January 31, 2003, expires July 2003. 14 pages. "Watchers are defined as entities that request (i.e., subscribe to) information about a resource, using the SIP event framework, RFC 3265 ["Session Initiation Protocol (SIP)-Specific Event Notification"]. There is fairly complex state associated with these subscriptions. This state includes the identity of the subscriber, the state of the subscription, and so on. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. An important application of this is the ability for a user to find out the set of subscribers to their presentity [11]. This would allow the user to provide an authorization decision for the subscription. To support subscriptions to watcher information, two components are needed. The first is the definition of a SIP event template-package for watcher information. The other is the definition of a data format to represent watcher information. The former is specified in 'A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)', and the latter is specified here. This document also uses the terms subscriber, watcher, subscription, notification, watcherinfo subscription, watcherinfo subscriber, and watcherinfo notification... Watcher information is an XML document that MUST be well-formed and SHOULD be valid. Watcher information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying watcherinfo documents and document fragments..." [IETF source]

• "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)." By Jonathan Rosenberg (dynamicsoft). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-winfo-package-05.txt'. January 31, 2003, expires July 2003. 20 pages. "This document defines the watcher information template-package for the SIP event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself... A template-package has all the properties of a regular SIP event package. However, it is always associated with some other event package, and can always be applied to any event package, including the template-package itself. The template-package defined here is for watcher information, and is denoted with the token "winfo". For any event package, such as presence, there exists a set (perhaps an empty set) of subscriptions that have been created or requested by users trying to ascertain the state of a resource in that package. This set of subscriptions changes over time as new subscriptions are requested by users, old subscriptions expire, and subscriptions are approved or rejected by the owners of that resource. The set of users subscribed to a particular resource for a specific event package, and the state of their subscriptions, is referred to as watcher information. Since this state is itself dynamic, it is reasonable to subscribe to it in order to learn about changes to it. The watcher information event template-package is meant to facilitate exactly that -- tracking the state of subscriptions to a resource in another package..." [IETF source]

Partial Presence

• "Presence Information Data format (PIDF) Extension for Partial Presence." By Mikko Lonnfors, Eva Leppanen, and Hisham Khartabil (Nokia). IETF SIMPLE Working Group, Internet Draft. Reference: draft-ietf-simple-partial-pidf-format-00. January 21, 2004, expires July 21, 2004. 14 pages. Section 7 provides the XML Schema for the application/pidf-partial+xml data format. "Presence Information Document Format (PIDF) specifies baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information... The new MIME type works in <tuple> element level so that it allows indicating if new tuples have been added, previously received tuples have changed, or that some tuples have been removed. These modifications are always relative to previously received presence information." [IETF source]

• "Partial Notification of Presence Information." By Mikko Lonnfors, Jose Costa-Requena, Eva Leppanen, and Hisham Khartabil (Nokia). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-partial-notify-01'. January 21, 2004, expires July 21, 2004. 17 pages. "A Presence service can have constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Limitations can also be caused by the interface between the terminal and the network, i.e., radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and to increase transport efficiency, by introducing a mechanism called partial notification." [IETF source]

• "Partial Publication of Presence Information." By Mikko Lonnfors, Eva Leppanen, and Aki Niemi (Nokia). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-lonnfors-simple-partial-publish-00'. February 6, 2004, expires August 6, 2004. 12 pages. See the announcement. "The size of the published presence information document may be large. A presence user agent publishes its full event state of presence information in every subsequent publication as specified in 'An Event State Publication Extension to the Session Initiation Protocol (SIP).' This is done regardless what presence information has been changed compared to the earlier publications. It may not be reasonable to send the full presence information over low bandwidth and high latency links when only a part of presence information changes. This memo presents a solution that aids in reducing the impact of those constrains and to increase transport efficiency, by introducing a mechanism called partial publication." [IETF source]

• "Requirements for Efficient Delivery of Presence Information." By Mikko Lonnfors, Jose Costa-Requena, Eva Leppanen, and Hisham Khartabil (Nokia). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-presinfo-deliv-reg-01'. October 3, 2003, expires April 2, 2004. 9 pages. "A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. if presence information is delivered over radio links with high latency and low bandwidth. This memo presents requirements for a solution that can aid to reduce the impacts of these constrains and helps to increase efficiency." [IETF source]

Filtering

• "An Extensible Markup Language (XML) Based Format for Event Notification Filtering." By Hisham Khartabil, Eva Leppanen, Mikko Lonnfors, and Jose Costa-Requena (Nokia). IETF SIMPLE Working Group, Internet Draft, 'draft-ietf-simple-filter-format-00'. February 2, 2004, expires August 2, 2004. 19 pages. Section 7 supplies the XML Schema for Filter Criteria. See the announcement. "The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format... Filtering is a mechanism for defining the preferred content to be delivered and for specifying the rules for when the content should be delivered... The filtering mechanism is expected to be particularly valuable to users of mobile wireless access devices. The characteristics of the devices typically include high latency, low bandwidth, low data processing capabilities, small display, and limited battery power. Such devices can benefit from the ability to filter the amount of information generated at the source of the event notification. ... The structure of the filter criteria is described using the XML Schema. The filter criteria is presented as an XML document. The XML document contains the user's preference when notifications are to be sent to it and what they are to contain. The scope of the "when" part is triggering. The triggering is defined as enabling a subscriber to specify triggering rules for notifications where the criteria are based on changes of the package specific state information, e.g., for the presence information document the change in the value of the <status> element..." [IETF source]

• "Requirements for Filtering of Watcher Information." By Krisztian Kiss, Eva Leppanen, and Hisham Khartabil (Nokia). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-winfo-filter-reqs-01'. January 26, 2004, expires July 26, 2004. 10 pages. "This document defines a set of structured requirements whereby a watcher information subscriber (client) may select specific information to be received in the watcher information notification sent by the notifier (server). The purpose is to limit the content so that only essential information is delivered by the server. ... SIP event notification defines a general framework for subscriptions and notifications for SIP event packages. Concrete applications of the general event framework to a specific group of events are described for user presence and watcher information. The watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or rejected. A client can subscribe to this information. As the inherent usage of event packages grows, the client needs some mechanisms for controlling the event notifications at the source... These mechanisms are expected to be particularly valuable to users of wireless devices. The characteristics of these devices typically include low bandwidth, low data processing capabilities, small display and limited battery power. Such devices can benefit from the ability to filter the amount of information generated at the source of the event notification. However, it is expected that the control mechanisms for event notifications add value for all users irrespectively of their device or network access characteristics..." [IETF source]

• "Functional Description of Event Notification Filtering." By Hisham Khartabil, Eva Leppanen, Mikko Lonnfors, and Jose Costa-Requena (Nokia). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-event-filter-funct-00'. February 3, 2004, expires August 3, 2004. 26 pages. See the announcement. "The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. The format of the filter is outside the scope of this document... Filtering is a mechanism for controlling the content of event notifications. Additionally, the subscriber may specify the rules for when a notification should be sent to it... The filtering mechanism is expected to be particularly valuable to users of mobile wireless access devices. The characteristics of the devices typically include high latency, low bandwidth, low data processing capabilities, small display, and limited battery power. Such devices can benefit from the ability to filter the amount of information generated at the source of the event notification... The XML format for defining the filter is described in "An Extensible Markup Language (XML) Based Format for Event Notification Filtering"." [IETF source]

• "Requirements for Presence Specific Event Notification Filtering." By Tim Moran, Hisham Khartabil (Nokia), and Eva Leppanen (Nokia). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-pres-filter-reqs-03'. January 26, 2004, expires July 26, 2004. 13 pages. "This document defines a set of structured requirements whereby a presence information subscriber may select specific information to be received in the presence information notification sent by the notifier. The purpose is to limit the content and frequency of notifications so that only essential information on a need basis is delivered by the server... There are two parts to the event filtering model. From a Presence service view point, presence information is collected by a Presence Agent and is published by one or more Presence User Agents. The first part of the model enables the watcher to limit the presence information delivered to it. Allowing the watcher to select the information of interest to it results in the ability to limit the contents of a presence information document, therefore reducing the size of a notification message. The second part of the model defines the triggering. In a filter-less subscription, it might be a Presence Agent's default policy to deliver a notification message every time there is a change to the presence information of a presentity or whenever a PUA publishes new and updated presence information from its own point of view. This model enables the watcher to select the events or changes in presents information that trigger notifications to be sent. Other changes that are not defined as triggers in a filter do not result in a notification message being delivered to the watcher..." [IETF source]

Presence and Wireless

• "Requirements for Presence Service in 3GPP Wireless Systems." Edited by Krisztian Kiss (Nokia). IETF Network Working Group, Internet Draft. Reference: 'draft-kiss-simple-presence-wireless-reqs-03'. October 18, 2003, expires April 19, 2003. 13 pages. This Internet-Draft lists the requirements for Presence Service in 3GPP wireless systems,[viz.]: (1) "IP Multimedia Subsystem (IMS) (Stage 2) - Release 5" [GPP TS 23.228, Version 6.3.0]; (2) "Signaling flows for the IP Multimedia call control based on SIP and SDP" [3GPP TS 24.228, Version 5.6.0]; (3) "IP Multimedia Call Control Protocol based on SIP and SDP, stage 3" [3GPP TS 24.229, Version 6.0.0]. The 3GPP Presence Service requirements are defined in 3GPP TS 22.141: "Presence Service, Stage 1"; the 3GPP Presence Service architecture is defined in 3GPP TS 23.141: "Presence Service, Architecture and Functional Description, Stage 2"; presence service information flows and protocol details are defined in 3GPP TS 24.841: "Presence service based on Session Initiation Protocol (SIP); Functional models, information flows and protocol details". The requirements on the Session Initiation Protocol (SIP) for the Release 5 of the 3GPP IP Multimedia Subsystem are described in "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)." ... This document does not document requirements that have led to the creation and work in progress on a number of SIMPLE WG specifications, i.e. subscriptions and notifications of user presence, the SIP event notification extension for collections, the SIP Event Template-Package for Watcher Information documents, the content indirection mechanism and the SIMPLE Presence Publication Mechanism . Rather this document lists only requirements that are additional to those that have led to the mechanisms proposed in these documents. The document also assumes the usage of the Common Presence and Instant Messaging (CPIM) Presence Information Data Format (PIDF) as the default presence document data format; however some of the requirements presented here might require extensions to PIDF..." See also 3GPP IETF Dependencies and Priorities. [IETF source]

• "Requirements for Instant Messaging in 3GPP Wireless Systems." By Aki Niemi (Nokia). IETF Network Working Group, Internet Draft. Reference: 'draft-niemi-simple-im-wireless-reqs-02'. 12 pages. "This document lists the requirements specific to 3GPP wireless Instant Messaging systems... Within the 3GPP IP Multimedia Core Network Subsystem (IMS) Messaging work, two types of messaging services have been identified: (1) Immediate Messaging A sender expects near real time message delivery. Typically, the sender is aware of the availability of the recipient a priori, possibly through the use of the presence service. (2) Session Based Messaging A sender and a recipient have to join a messaging session before messages can be exchanged as part of the session. The participants of the session expect near real time delivery of messages. Mainly, the intended application for session based messaging are multiparty messaging sessions, i.e., chat rooms, where a group of participants exhange instant messages with each others. Both of these two messaging service types have properties which make the Session Initiation Protocol (SIP) very suitable for addressing their requirements..." [IETF source]

Ad hoc Lists and Exploders

"A lot of work is going on right now on 'adhoc list subscriptions', also under the moniker 'exploders' which allows you to subscribe to a list of users without first provisioning the list on the server. Also for Instant Messaging to a list of users without first provisioning the list on the server." [jr]

• "Ad-hoc Resource Lists using SUBSCRIBE in SIMPLE." By Orit Levin (Microsoft Corporation). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-levin-simple-adhoc-list-01.txt'. November 1, 2003, expires May 1, 2004. 14 pages. "This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can define an ad-hoc resource list, subscribe to it, and maintain it -- all within a single SUBSCRIBE dialog. Changes in the state of the resources are reported using NOTIFY within the same dialog in any standard SIMPLE format for conveying notifications for lists of resources or for individual resources and specified as 'accepted' during the SUBSCRIBE dialog establishment." [IETF source]

• "Providing a Session Initiation Protocol (SIP) Application Server with a List of URIs." By Gonzalo Camarillo (Ericsson) and Adam Roach (dynamicsoft). IETF SIPPING Working Group, Internet Draft. Reference: 'draft-camarillo-sipping-uri-list-01.txt'. February 6, 2004, expires August 6, 2004. 11 pages. "This document describes how a user agent can provide an application server with a list of URIs. The way the application server uses the URIs in the list is service specific." [IETF source]

• "Requirements and Framework for Session Initiation Protocol (SIP) Exploder Invocation." By Gonzalo Camarillo (Ericsson). IETF SIPPING Working Group, Internet Draft. Reference: 'draft-camarillo-sipping-exploders-02.txt'. February 6, 2004, expires August 6, 2004. 9 pages. "This document describes the need for SIP exploders and provides requirements for their invocation. Additionaly, it defines a framework which includes all the SIP extensions needed to meet these requirements." [IETF source]

• "A Transaction Event Package for the Session Initiation Protocol (SIP)." By Gonzalo Camarillo (Ericsson) and Miguel A. Garcia-Martin (Nokia). IETF SIPPING Working Group, Internet Draft. Reference: 'draft-camarillo-sipping-transac-package-00.txt'. February 6, 2004, expires August 6, 2004. 16 pages. "SIP provides a SIP Events notification framework that is extensible throught the addition of event packages. This document defines a transaction event package for the SIP Events notification, along with a data format used in notifications for this package. The transaction package allows users to subscribe to a resource in an application server and receive notifications about the changes in state of transactions the application server initiates as part of a service. Additionally, we define a new SIP Associated-Transactions-State header field that allows a server to return a subscrible URI that provides transactions notification information." [IETF source]

Core Presence

• "A Presence Event Package for the Session Initiation Protocol (SIP)." By Jonathan Rosenberg (dynamicsoft). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-presence-10.txt'. January 31, 2003, expires July 2003. 27 pages. "This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework... Presence, also known as presence information, conveys the ability and willingness of a user to communicate across a set of devices. RFC 2778 defines a model and terminology for describing systems that provide presence information. In that model, a presence service is a system that accepts, stores, and distributes presence information to interested parties, called watchers. A presence protocol is a protocol for providing a presence service over the Internet or any IP network... [The use of SIP as a presence protocol] is accomplished through a concrete instantiation of the general event notification framework defined for SIP, and as such, makes use of the SUBSCRIBE and NOTIFY methods defined there. Specifically, this document defines an event package, as described in RFC 3265. SIP is particularly well suited as a presence protocol. SIP location services already contain presence information, in the form of registrations. Furthermore, SIP networks are capable of routing requests from any user on the network to the server that holds the registration state for a user. As this state is a key component of user presence, those SIP networks can allow SUBSCRIBE requests to be routed to the same server. This means that SIP networks can be reused to establish global connectivity for presence subscriptions and notifications. This event package is based on the concept of a presence agent, which is a new logical entity that is capable of accepting subscriptions, storing subscription state, and generating notifications when there are changes in presence. The entity is defined as a logical one, since it is generally co-resident with another entity..." [IETF source]

• "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists." By Adam Roach, Jonathan Rosenberg, and Ben Campbell (dynamicsoft). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-ietf-simple-event-list-04'. June 13, 2003, expires December 12, 2003. 42 pages. ""This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. In many cases, a subscriber has a list of resources they are interested in. Without some aggregating mechanism, this will require the subscriber generate a SUBSCRIBE request for each resource about which they want information. For environments in which bandwidth is limited, such as wireless networks, subscribing to each resource individually is problematic. Some specific problems are: (1) Doing so generates substantial message traffic, in the form of the initial SUBSCRIBE requests for each resource, and the refreshes of each individual subscription. (2) o The notifier may insist on low refresh intervals, in order to avoid long lived subscription state. (3) The notifier may generate NOTIFY requests more rapidly than the subscriber desires, causing NOTIFY traffic at a greater volume than is desired by the subscriber. To solve these problems, this specification defines an extension to RFC 3265 that allows for requesting and conveying notifications for lists of resources. A resource list is identified by a URI and it represents a list of zero or more URIs. Each of these URIs is an identifier for an individual resource for which the subscriber wants to receive information... The root document of the multipart/related body MUST be a Resource List Meta-Information (RLMI) document. It is of type application/rlmi+xml. This document contains the meta-information for the resources contained in the notification." [IETF source]

• "SIMPLE Presence Publication Requirements." By Ben Campbell (dynamicsoft), Sean Olson (Microsoft), Jon Peterson (NeuStar, Inc), Jonathan Rosenberg (dynamicsoft), and Brian Stucker (Nortel Networks, Inc). IETF SIMPLE Working Group, Internet Draft, 'draft-ietf-simple-publish-reqs-00'. February 11, 2003, expires August 12, 2003. 11 pages. "This document describes requirements for an extension to the Session Initiation Protocol (SIP). The purpose of this extension would be to create a means for publishing event state used within the framework for SIP Event Notification (RFC3265). The first application of this extension is targeted at the publication of presence information as defined by the SIMPLE working group." [IETF source]

• "An Event State Publication Extension to the Session Initiation Protocol (SIP)." Edited by Aki Niemi (Nokia). IETF SIP Working Group, Internet Draft, 'draft-ietf-sip-publish-03'. February 13, 2004, expires August 13, 2004. 40 pages. "This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose." [IETF source]

• 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. See the Zvon hyperlinked version. "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."

• 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. See the Zvon hyperlinked version. "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."

• Session Initiation Protocol (SIP)-Specific Event Notification. By Adam Roach (dynamicsoft). IETF Network Working Group, Request for Comments 3265. Updates RFC 2543. June 2002. "This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Concrete uses of the mechanism described in this document may be standardized in the future. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification."

Instant Messaging

• Session Initiation Protocol (SIP) Extension for Instant Messaging. Ben Campbell (dynamicsoft), Jonathan Rosenberg (dynamicsoft), Henning Schulzrinne (Columbia University), Christian Huitema (Microsoft Corporation), and David Gurle (Microsoft Corporation). IETF Network Working Group, Request for Comments #3428. December 2002. 18 pages. "Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request."

• [June 15, 2004] Last Call Review for IETF Indication of Message Composition for Instant Messaging." - The Internet Engineering Steering Group (IESG) has announced a Last Call review of the Internet Draft Indication of Message Composition for Instant Messaging, prepared by the IETF's SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group. The Internet Draft describes an XML-based status message that can be used to indicate the current composing status to participants in an IM conversation. "In instant messaging (IM) systems, it is useful to know during an IM conversation that the other party is composing a message, e.g., typing or recording an audio message. The document defines a new status message content type and XML namespace that conveys information about a message being composed. Status messages are carried as XML, as instances of the XML Schema defined in the draft and labeled as an application/im-iscomposing+xml content type." The draft distinguishes two types of messages used in an IM conversation: one is the "content message" which "conveys actual content between two or more users engaged in an instant messaging conversation; the other is the "status message" which "indicates the current composing status to the other participants in a conversation. The status message can indicate the composition of a message of any type, including text, voice or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. The Internet Draft Indication of Message Composition for Instant Messaging is legally encumbered, according to an IETF Patent Disclosure and Licensing Declaration from Microsoft on the version -00 'is-composing ' draft of March 2004. Microsoft declined to make a royalty-free declaration provided in the IPR Template ("Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers"), electing instead a RAND declaration for two issued patents and potentially for related unpublished pending patent application(s). The IESG solicits public comment on this Internet Draft by 2004-06-28.

• "Indication of Message Composition for Instant Messaging." By Henning Schulzrinne (Columbia University, Department of Computer Science); WWW: http://www.cs.columbia.edu/~hgs. Acknowledgements: Contributions from Niemi Aki, Ben Campbell, Miguel Garcia, Christian Jansson, Cullen Jennings, Hisham Khartabil, Jonathan Rosenberg, and Xiaotao Wu. IETF Network Working Group, Internet Draft. May 15, 2004, expires November 13, 2004. Reference: 'draft-ietf-simple-iscomposing-01'. 13 pages. "In instant messaging (IM) systems, it is useful to know during an IM conversation that the other party is composing a message, e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves..." Note the Microsoft Patent Declarations (and RAND License) with respect to 'draft-ietf-simple-iscomposing-00'. [IETF source: http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-01.txt]

• "is-composing Indication for Instant Messaging Using the Session Initiation Protocol (SIP)." By Henning Schulzrinne (Columbia University, Department of Computer Science); WWW: http://www.cs.columbia.edu/~hgs. IETF Network Working Group, Internet Draft. March 2004, expires August 30, 2004. Reference: 'draft-ietf-simple-iscomposing-00'. By definition, instant messaging is message-based, i.e., a user composes a message by typing, speaking or recording a video clip. This message is then sent. Unlike email, instant messaging is often conversational, so that the other party is waiting for a response. If no response is forthcoming, an IM session participant may erroneously assume that either the communication partner has left or that it is her turn to type again, leading to messaging 'crossing on the wire'. To avoid this uncertainty, a number of commercial instant messaging systems feature an 'is-typing' indication that is set as soon as one party starts typing a message. In this document, we describe a generalized version of this indication. A status message is delivered to the IM recipient in the same manner as the messages themselves. The is-composing messages can announce the composition of any media type, not just text. For example, it might be used if somebody is recording an audio or video clip. In addition, it can be extended to convey other IM user states in the future... In instant messaging systems, it is useful to know that the other party is composing a message, e.g., typing. This document defines a new content type and XML namespace that conveys information about a message being composed. The message could be of any type, including text, voice or video. We model user behavior as states, initially limited to Idle and Active. When the user first starts composing, the state becomes Active and an isComposing message containing a <state> element indicating 'active' is sent. As long as the user produces message content, the user remains in state Active. The composing user MAY specify a time-out interval measured in seconds, using the <timeout> element, after which the isComposing message is resent to refresh the state. The refresh period SHOULD be no shorter than 60 seconds. If the <timeout> element is omitted, the receiver should assume that no refresh messages will be sent. Receivers MUST be able to handle multiple isComposing messages with 'active' state regardless of the refresh interval..." Note the Microsoft Patent Declarations (and RAND License) with respect to 'draft-ietf-simple-iscomposing-00'. Note update in preceding reference. [IETF source: http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing-00.txt]

• "The Message Session Relay Protocol." Reference: IETF SIMPLE Working Group, Internet Draft 'draft-ietf-simple-message-sessions-03' Date: January 27, 2004. "This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting a series of Instant Messages within a session. MSRP sessions are managed using the Session Description Protocol (SDP) offer/answer model carried by a signaling protocol such as the Session Initiation Protocol (SIP)." [IETF source]

• "SIMPLE Instant Messaging Sessions (SIMS)." By Cullen Jennings, Rohan Mahy, and Juhee Garg (Cisco Systems, Inc). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-jennings-simple-sims-00.txt'. February 9, 2004, expires August 9, 2004. 75 pages. "This document defines a protocol for conveying binary MIME content in near-real time, peer-to-peer or through one or more relays, with the opportunity for store and forward. SIMS (SIMPLE Instant Messaging Sessions) can be used as a standalone protocol, or in conjunction with a rendezvous or session setup protocol such as SIP. While SIMS was originally envisioned as an alternative to the Media Session Relay Protocol (MSRP), one section of this document describes how these ideas could be applied as MSRP extensions for features such as chunking, relay connection multiplexing, and prevention of head-of-line blocking." [IETF source]

• "SIMPLE Session and Relay IM Protocol Requirements." By Rohan Mahy (Cisco Systems, Inc), Cullen Jennings (Cisco Systems, Inc), Orit Levin (Microsoft Corporation), Avshalom Houri (IBM), and Mary Barnes (Nortel Networks). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-mahy-simple-im-protocol-reqs-00.txt'. February 9, 2004, expires August 9, 2004. 7 pages. See the announcement. "This document defines requirements for sessions of messages in SIMPLE. These requirements apply to the Message Session Relay Protocol (MSRP)... The IETF SIMPLE working group has identified a number of scenarios where using a separate protocol for bulk messaging is desirable. In particular, the SIMPLE WG will use this facility to handle a sequence of messages as a session of media setup using SIP just like any other media. The 'Message Session Relay Protocol (MSRP)' defines a protocol for delivering such messages point-to-point, but does not define any relay functionality. This document takes into consideration the 'Guidelines for Instant Message Sessions' and brings into the focus essential requirements on the MSRP core protocol and additional requirements for extensions to MSRP that define relay functionality. [IETF source]

General Specifications

• "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)." By Jonathan Rosenberg (dynamicsoft). IETF SIMPLE Working Group, Internet Draft,. Reference: 'draft-rosenberg-simple-messaging-requirements-01'. February 12, 2004, expires August 12, 2004. 18 pages. "This specification defines a set of requirements for new capabilities for instant messaging in SIP-based systems. The Session Initiation Protocol (SIP) defines several specifications that support Instant Messaging (IM). The SIP MESSAGE method allows for 'page-mode' messaging, offering a service similar to Short Message Service (SMS) in wireless networks. A more advanced capability, called session mode messaging, uses the SIP INVITE method to establish a session whose media type is messaging. This allows for many SIP capabilities to be directly applied to instant messaging, such as conferencing. However, there are many additional features that exist in current, proprietary IM systems. Some of these features do not require protocol extensions in order to be deployed (IM message archival, for example). However, others do. This specification provides requirements for a number of advanced IM features which require additional standardization activity to support. It does not cover features which can be achieved with existing protocols and specifications. It is also limited to instant messaging only, and does not consider presence..." Covers topics such as: Delivery Status Reporting; Is-Composing; Content Capabilities; Page-Mode Groups. [IETF source]

• "Inter-domain Requirements for SIMPLE." By Orit Levin (Microsoft Corporation) and Avshalom Houri (IBM). IETF SIMPLE Working Group, Internet Draft. Reference: 'draft-levin-simple-interdomain-reqs-00.txt'. February [01], 2004, expires August 1, 2004. 12 pages. See the announcement. "This document defines the inter-domain SIMPLE interface and identifies the requirements particular to this interface for secure and scalable exchange of presence information. SIMPLE defines a set of extensions to the existing protocols (e.g., SIP) and some new technologies (e.g., XCAP) in order to implement presence and instant messaging (IM) systems. The basic SIMPLE architecture relies completely on a peer-to-peer Internet model for exchanging both presence and IM data. This open system architecture remains an important part of the core SIMPLE functionality. As SIMPLE has matured and became an important technology for implementing presence and IM, different deployment models have been contributing to SIMPLE architecture. The most obvious example is the 3GPP requirements for wireless mobile access. We expect that with growing SIMPLE popularity, more architectural needs will be identified... This document defines the inter-domain SIMPLE interface and identifies the requirements particular to this interface for secure and scalable exchange of presence information." [IETF source]

Reference Specifications

• SIP: Session Initiation Protocol. By J. Rosenberg (dynamicsoft), H. Schulzrinne (Columbia U.), G. Camarillo (Ericsson), A. Johnston (WorldCom), J. Peterson (Neustar), R. Sparks (dynamicsoft), M. Handley (ICIR), E. Schooler (AT&T). IETF Network Working Group. Request for Comments: 3261. June 2002. 269 pages. "This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols."

• Common Presence and Instant Messaging (CPIM). IETF Network Working Group, Internet Draft. By Dave Crocker (Brandenburg InternetWorking), Athanassios Diacakis (Network Projects Inc), Florencio Mazzoldi (Network Projects Inc), Christian Huitema (Microsoft Corporation), Graham Klyne (Baltimore Technologies), Jonathan Rosenberg (dynamicsoft), Robert Sparks (dynamicsoft), Hiroyasu Sugano (Fujitsu Laboratories Ltd), and Jon Peterson (NeuStar, Inc). Reference: 'draft-ietf-impp-cpim-03'. August 14, 2002, expires February 12, 2003. 35 pages. "Semantics and data formats for common services of Instant Messaging and online Presence, independent of underlying transfer infrastructure, are described. The CPIM profile meets the requirements specified in RFC 2779 using a minimalist approach allowing interoperation of a wide range of IM and Presence systems... This memo focuses on interoperation. Accordingly only those aspects of Presence and IM that require interoperation are discussed. For example, the "open instant inbox" operation is not applicable as this operation occurs within a single IM system and not across systems. Service behavior is described abstractly in terms of operations invoked between the consumer and provider of a service... The parameters for each operation are defined using an abstract syntax. Although the syntax specifies the range of possible data values, each Presence and IM service must specify how well-formed instances of the abstract representation are encoded as a concrete series of bits..." Note: The Common Presence and Instant Messaging (CPIM) specification was referenced in the SIMPLE WG Charter, but subsequently this document expired. According to a [2004-02-16] note from Jonathan Rosenberg, "the CPIM specification referenced in the charter has been split into three separate documents... these documents have been approved by the IESG and are awaiting their publication as formal RFCs"; see (1) Common Profile for Instant Messaging (CPIM), (2) Common Profile for Presence (CPP), and (3) Address Resolution for Instant Messaging and Presence.

• Congestion Control Principles. IETF Network Working Group. Request for Comments 2914, BCP 41. Category: Best Current Practice. Edited by Sally Floyd (AT&T Center for Internet Research at ICSI - ACIRI). September 2000. "The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols."

IETF Session Initiation Protocol (SIP) Working Group

"The Session Initiation Protocol (SIP) working group is chartered to continue the development of SIP, currently specified as proposed standard RFC 2543. SIP is a text-based protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. The main work of the group involves bringing SIP from proposed to draft standard, in addition to specifying and developing proposed extensions that arise out of strong requirements..."

• SIP Working Group Charter
• Session Initiation Protocol (SIP) Working Group Supplemental Home Page
• Session Initiation Protocol Discussion Archive
• SIP FAQ document

IETF Session Initiation Proposal Investigation (SIPPING) Working Group

"The Session Initiation Protocol Project INvestiGation (SIPPING) working group is chartered to document the use of SIP for several applications related to telephony and multimedia, and to develop requirements for any extensions to SIP needed for those applications. Such requirements will be referred to the SIP working group for development of any new SIP method or header."

• SIPPING Working Group Charter
• Session Initiation Protocol INvestiGation (SIPPING) Working Group Supplemental Home Page
• Sipping Discussion Archive

IETF Geographic Location/Privacy (GEOPRIV) Working Group

"Some applications need to acquire geographic location information about certain resources or entities. These applications include navigation, emergency services, management of equipment in the field, and other location-based services... The primary task of this working group will be to assess the the authorization, integrity and privacy requirements that must be met in order to transfer such information, or authorize the release or representation of such information through an agent."

• Working Group Charter
• Auxillary Pages of the IETF GEOPRIV Working Group
• Mail list archives

IETF Instant Messaging and Presence Protocol (IMPP) Working Group

"This working group will eventually define protocols and data formats necessary to build an internet-scale end-user presence awareness, notification and instant messaging system. Its initial task is to determine specific design goals and requirements for such a service. The design goals document will be submitted for IETF-wide review, and based on that review, the group's charter will be extended..." Note: most of the WG's work is concluded as of 2004-02, but its published specifications are referenced in SIMPLE and XMPP documents.

• Working Group Charter
• IMPP Information Homepage
• Discussion List Archives
• Key specifications:
  • Common Presence and Instant Messaging: Message Format
  • Common Presence and Instant Messaging (CPIM) Presence Information Data Format.
  • Address Resolution for Instant Messaging and Presence
  • Common Profile for Presence (CPP)
  • Common Profile for Instant Messaging (CPIM)
  • Common Presence and Instant Messaging (CPIM)

IETF Centralized Conferencing (XCON) Working Group

Dealing with Floor Control Signaling, Conference Policy Control Protocol (CPCP), Media Policy, and Conferencing Scenarios. "The focus of this working group is to develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Tightly-coupled conferences have a central point of control and authorization (known as a focus) so they can enforce specific media and membership relationships, and provide an accurate roster of participants... Due to the centralized architecture of the WG, XCON's mechanisms will place requirements on the signaling protocol used between the focus and the participants. At a high level, the signaling protocol must be able to establish, tear down, modify, and perform call control operations on multimedia streams, including voice, video, and instant messaging, in both a centralized and distributed mixing architecture. SIP will be the reference session signaling protocol used for examples; however, none of the XCON solutions themselves will be signaling protocols, nor will XCON extend existing signaling protocols..."

• Working Group Charter
• XCON: Centralized Conferencing Working Group Supplemental Home Page
• Discussion Archive
• "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Conference Policy."
• "Requirements for Conference Policy Control Protocol."

IETF Extensible Messaging and Presence Protocol (XMPP) Working Group

"XMPP is an open, XML-based protocol for near real-time extensible messaging and presence. It is the core protocol of the Jabber Instant Messaging and Presence technology which is currently deployed on thousands of servers across the Internet and is used by millions of people worldwide. The XMPP working group shall adapt the XMPP for use as an IETF Instant Messaging and Presence technology."

• Working Group Charter
• XMPP WG Discussion List: Post to xmppwg@jabber.org; see the mail list archives
• "Extensible Messaging and Presence Protocol (XMPP)" - Local references.

W3C Platform for Privacy Preferences (P3P) Project

"The Platform for Privacy Preferences Project (P3P) enables Web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. P3P user agents will allow users to be informed of site practices and to automate decision-making based on these practices when appropriate."

• W3C P3P Web site

• W3C Privacy Activity Statement

• "W3C Releases Platform for Privacy Preferences (P3P) Version 1.1"
• IBM Submits EPAL Version 1.2 Privacy Specification to W3C."
• "Platform for Privacy Preferences (P3P) Project" - Local references.

Liberty Alliance

"The Liberty Alliance vision is one of a networked world in which individuals and businesses can more easily interact with one another while respecting the privacy and security of shared identity information. A consortium of more than 160 technology and consumer-facing organizations, the Liberty Alliance Project was formed in September 2001 to establish an open standard for federated network identity. Federated identity answers many of the inefficiencies and complications of network identity management that both businesses and consumers face in today's world. Federated identity allows users to 'link' elements of their identity between accounts without centrally storing all of their personal information..."

• Liberty Alliance Personal Profile Service Specifications
• "Privacy and Security Best Practices"
• "Privacy Preference Expression Languages."
• Liberty Alliance web site
• "Liberty Alliance Specifications for Federated Network Identification and Authorization" - Local references.

3rd Generation Partnership Project (3GPP)

"The 3rd Generation Partnership Project (3GPP) is a collaboration agreement that currently includes Organizational Partners ARIB, CCSA, ETSI, T1, TTA, and TTC. Its scope includes the maintenance and development of the Global System for Mobile communication (GSM) Technical Specifications and Technical Reports including evolved radio access technologies e.g., General Packet Radio Service (GPRS) and Enhanced Data rates for GSM Evolution (EDGE)."

• 3GPP IETF Dependencies and Priorities. Note that many of the SIMPLE and SIP WG specifications are represented in the table.
• 3GPP web site
• 3GPP-IETF Standardization Collaboration

Open GIS Consortium, Inc. (OGC)

"Open GIS Consortium, Inc. (OGC) is a member-driven, non-profit international trade association that is leading the development of geoprocessing interoperability computing standards. OGC works with government, private industry, and academia to create open and extensible software application programming interfaces for geographic information systems (GIS) and other mainstream technologies. Its adopted specifications are available for the public's use at no cost."

• OpenGIS Consortium Home Page
• OpenGIS Implementation Specifications
• OpenGIS Geography Markup Language (GML) Implementation Specification. Version 3.0. OpenGIS Project Document Number OGC 02-023r4.
• OGC Schema Repository
• GML FAQ document
• "Geography Markup Language (GML)" - Local references.

OMA Push to talk over Cellular (PoC) WG

"The initial work of the Working Group will be focused on the tasks required to develop specifications for an open standard to enable adoption of PoC service over mobile networks. PoC service is a half-duplex form of communications that allows users to engage in immediate communication with one or more receivers, similar to Walkie Talkie type operation, simply by pushing a button on their handsets."

• OMA PoC Working Group web site
• WG public documents
• IETF Work Relating to PoC. By Dean Willis. January 05, 2004. Reference: OMA-POC-2004-0006-POC-IETF-SIP-SIPPING-SIMPLE-XCON-dependency.