Skip to main content

SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)
RFC 6914

Document Type RFC - Informational (April 2013)
Author Jonathan Rosenberg
Last updated 2015-10-14
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Robert Sparks
Send notices to (None)
RFC 6914
Internet Engineering Task Force (IETF)                      J. Rosenberg
Request for Comments: 6914                                   jdrosen.net
Category: Informational                                       April 2013
ISSN: 2070-1721

       SIMPLE Made Simple: An Overview of the IETF Specifications
                for Instant Messaging and Presence Using
                 the Session Initiation Protocol (SIP)

Abstract

   The IETF has produced many specifications related to Presence and
   Instant Messaging with the Session Initiation Protocol (SIP).
   Collectively, these specifications are known as SIP for Instant
   Messaging and Presence Leveraging Extensions (SIMPLE).  This document
   serves as a guide to the SIMPLE suite of specifications.  It
   categorizes the specifications, explains what each is for, and how
   they relate to each other.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6914.

Rosenberg                     Informational                     [Page 1]
RFC 6914                   Simple Made Simple                 April 2013

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Presence . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Core Protocol Machinery  . . . . . . . . . . . . . . . . .  4
     2.2.  Presence Documents . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Privacy and Policy . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Provisioning . . . . . . . . . . . . . . . . . . . . . . .  7
     2.5.  Federation . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.6.  Optimizations  . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Instant Messaging  . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Page Mode  . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Session Mode . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  IM Chat Rooms  . . . . . . . . . . . . . . . . . . . . . . 11
     3.4.  IM Features  . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 12

1.  Introduction

   The IETF has produced many specifications related to Presence and
   Instant Messaging with the Session Initiation Protocol (SIP)
   [RFC3261].  Collectively, these specifications are known as SIP for
   Instant Messaging and Presence Leveraging Extensions (SIMPLE).  These
   specifications cover topics ranging from protocols for subscription
   and publication to presence document formats to protocols for
   managing privacy preferences.  The large number of specifications can
   make it hard to figure out exactly what SIMPLE is, what
   specifications cover it, what functionality it provides, and how
   these specifications relate to each other.

Rosenberg                     Informational                     [Page 2]
RFC 6914                   Simple Made Simple                 April 2013

   This document serves to address these problems.  It provides an
   enumeration of the protocols that make up the SIMPLE suite of
   specifications from IETF.  It categorizes them into related areas of
   functionality, briefly explains the purpose of each, and how the
   specifications relate to each other.  Each specification also
   includes a letter that designates its category [RFC2026].  These
   values are:

   S: Standards Track

   E: Experimental

   B: Best Current Practice

   I: Informational

2.  Presence

   SIMPLE provides for both presence and instant messaging (IM)
   capabilities.  Though both of these fit underneath the broad SIMPLE
   umbrella, they are well separated from each other and are supported
   by different sets of specifications.  That is a key part of the
   SIMPLE story; presence is much broader than just IM, and it enables
   communications using voice and video along with IM.

   The SIMPLE presence specifications can be broken up into:

   o  The core protocol machinery, which provides the actual SIP
      extensions for subscriptions, notifications, and publications

   o  Presence documents, which are XML documents that provide for rich
      presence and are carried by the core protocol machinery

   o  Privacy and policy, which are documents for expressing privacy
      preferences about how those presence documents are to be shown (or
      not shown) to other users

   o  Provisioning, which describes how users manage their privacy
      policies, buddy lists, and other pieces of information required
      for SIMPLE presence to work

   o  Optimizations, which are improvements in the core protocol
      machinery that were defined to improve the performance of SIMPLE,
      particularly on wireless links

Rosenberg                     Informational                     [Page 3]
RFC 6914                   Simple Made Simple                 April 2013

2.1.  Core Protocol Machinery

   RFC 6665, SIP-Specific Event Notification (S):  [RFC6665] defines the
      SUBSCRIBE and NOTIFY methods for SIP, forming the core of the SIP
      event notification framework.  To actually use the framework,
      extensions need to be defined for specific event packages.
      Presence is defined as an event package [RFC3856] within this
      framework.  Packages exist for other, non-presence related
      functions, such as message waiting indicators and dialog state
      changes.

   RFC 3856, A Presence Event Package for the Session Initiation
      Protocol (SIP) (S):  [RFC3856] defines an event package for
      indicating user presence through SIP.  Through this package, a SIP
      user agent (UA) can ask to be notified of the presence state of a
      presentity (presence entity).  The contents of the NOTIFY messages
      in this package are presence documents discussed in Section 2.2.

   RFC 4662, A Session Initiation Protocol (SIP) Event Notification
      Extension for Resource Lists (S):  [RFC4662] defines an extension
      to [RFC3265] (which has now been obsoleted by RFC 6665) that
      allows a client to subscribe to a list of resources using a single
      subscription.  The server, called a Resource List Server (RLS),
      will "expand" the subscription and subscribe to each individual
      member of the list.  Its primary usage with presence is to allow
      subscriptions to "buddy lists".  Without RFC 4662, a UA would need
      to subscribe to each presentity individually.  With RFC 4662, they
      can have a single subscription to all buddies.  A user can manage
      the entries in their buddy list using the provisioning mechanisms
      in Section 2.4.

   RFC 5367, Subscriptions to Request-Contained Resource Lists in the
      Session Initiation Protocol (SIP) (S):  [RFC5367] is very similar
      to RFC 4662.  It allows a client to subscribe to a list of
      resources using a single subscription.  However, with this
      mechanism, the list is included within the body of the SUBSCRIBE
      request.  In RFC 4662, it is provisioned ahead of time on the
      server.

   RFC 3903, Session Initiation Protocol (SIP) Extension for Event State
      Publication (S):  [RFC3903] defines the PUBLISH method.  With this
      method, a UA can publish its current state for any event package,
      including the presence event package.  Once an agent publishes its
      presence state, the presence server would send notifications of
      this state change using RFC 3856.

Rosenberg                     Informational                     [Page 4]
RFC 6914                   Simple Made Simple                 April 2013

2.2.  Presence Documents

   Once a user has generated a subscription to presence using the core
   protocol machinery, they will receive notifications (SIP NOTIFY
   requests) that contain presence information.  That presence
   information is in the form of an XML presence document.  Several
   specifications have been defined to describe this document format,
   focusing on rich, multimedia presence.

   RFC 3863, Presence Information Data Format (PIDF) (S):  [RFC3863]
      defines the baseline XML format for a presence document.  It
      defines the concept of a tuple as representing a basic
      communication modality and defines a simple status for it (open or
      closed).

   RFC 4479, A Data Model for Presence (S):  [RFC4479] extends the basic
      model in RFC 3863.  It introduces the concepts of device and
      person status and explains how these relate to each other.  It
      describes how presence documents are used to represent
      communications systems states in a consistent fashion.  More than
      RFC 3863, it defines what a presence document is and what it
      means.

   RFC 4480, RPID: Rich Presence Extensions to the Presence Information
      Data Format (PIDF) (S):  [RFC4480] adds many more attributes to
      the presence document schema, building upon the model in RFC 4479.
      It allows for indications of activities, moods, places and place
      types, icons, and indications of whether or not a user is idle.

   RFC 4481, Timed Presence Extensions to the Presence Information Data
      Format (PIDF) to Indicate Status Information for Past and Future
      Time Intervals (S):  [RFC4481] adds attributes to the presence
      document schema, again building upon the model in RFC 4479.  It
      allows documents to indicate status for the future or the past.
      For example, a user can indicate that they will be unavailable for
      voice communications from 2 p.m. to 3 p.m. due to a meeting.

   RFC 4482, CIPID: Contact Information for the Presence Information
      Data Format (S):  [RFC4482] adds attributes to the presence
      document schema for contact information, such as a vCard, display
      name, homepage, icon, or sound (such as the pronunciation of their
      name).

   RFC 5196, Session Initiation Protocol (SIP) User Agent Capability
      Extension to Presence Information Data Format (PIDF) (S):
      [RFC5196] adds even more attributes to the presence document
      schema, this time to allow indication of capabilities for the user

Rosenberg                     Informational                     [Page 5]
RFC 6914                   Simple Made Simple                 April 2013

      agent.  For example, the extensions can indicate whether a UA
      supports audio and video, what SIP methods it supports, and so on.

2.3.  Privacy and Policy

   The rich presence capabilities defined by the specifications in
   Section 2.2 introduces a strong need for privacy preferences.  Users
   must be able to approve or deny subscriptions to their presence and
   indicate what information such watchers can see.  In SIMPLE, this is
   accomplished through policy documents uploaded to the presence server
   using the provisioning mechanisms in Section 2.4.

   RFC 4745, Common Policy: A Document Format for Expressing Privacy
      Preferences (S):  [RFC4745] defines a general XML framework for
      expressing privacy preferences for both geolocation information
      and presence information.  It introduces the concepts of
      conditions, actions, and transformations that are applied to
      privacy-sensitive data.  The common policy framework provides
      privacy safety, a property by which network error or version
      incompatibilities can never cause more information to be revealed
      to a watcher than the user would otherwise desire.

   RFC 5025, Presence Authorization Rules (S):  [RFC5025] uses the
      framework of RFC 4745 to define a policy document format for
      describing presence-privacy policies.  Besides basic yes/no
      approvals, this format allows a user to control what kind of
      information a watcher is allowed to see.

   RFC 3857, A Watcher Information Event Template-Package for the
      Session Initiation Protocol (SIP) (S):  [RFC3857], also known as
      watcherinfo, provides a mechanism for a user agent to find out
      what subscriptions are in place for a particular event package.
      Though it was defined to be used for any event package, it has
      particular applicability for presence.  It is used to provide
      reactive authorization.  With reactive authorization, a user gets
      alerted if someone tries to subscribe to their presence, so that
      they may provide an authorization decision.  Watcherinfo is used
      to provide the alert that someone has subscribed to a user's
      presence.

   RFC 3858, An Extensible Markup Language (XML) Based Format for
      Watcher Information (S):  [RFC3858] is the companion to RFC 3857.
      It specifies the XML format of watcherinfo that is carried in
      notifications for the event template package in RFC 3857.

Rosenberg                     Informational                     [Page 6]
RFC 6914                   Simple Made Simple                 April 2013

2.4.  Provisioning

   Proper operation of a SIMPLE presence system requires that several
   pieces of data are correctly managed by the users and provisioned
   into the system.  These include buddy lists (used by the resource
   list subscription mechanism in RFC 4662) and privacy policies (such
   as those described by the XML format in [RFC5025]).

   In SIMPLE, management of this data is handled by the Extensible
   Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825].
   XCAP is used by the user agent to manipulate buddy lists, privacy
   policy, and other data that is represented by XML documents stored on
   a server.

   RFC 4825, The Extensible Markup Language (XML) Configuration Access
      Protocol (XCAP) (S):  [RFC4825] specifies XCAP, a usage of HTTP
      that allows a user agent to manipulate the contents of XML
      documents stored on a server.  It can be used to manipulate any
      kind of XML, and the protocol itself is independent of the
      particular schema of the data it is modifying.  XML schemas have
      been defined for buddy lists, privacy policies, and offline
      presence status, allowing all of those to be managed by a user
      with XCAP.

   RFC 5875, An Extensible Markup Language (XML) Configuration Access
      Protocol (XCAP) Diff Event Package (S):  [RFC5875] defines an
      extension to the SIP user agent configuration profile, allowing a
      user agent to learn about changes in its documents on an XCAP
      server.  With this mechanism, there can be a change made by
      someone else to a buddy list or privacy policy document, and a UA
      will find out that a new version is available.

   RFC 5874, An Extensible Markup Language (XML) Document Format for
      Indicating a Change in XML Configuration Access Protocol (XCAP)
      Resources (S):  [RFC5874] defines an XML format for indicating
      changes in XCAP documents.  It makes use of an XML diff format
      defined in [RFC5261].  It is used in conjunction with [RFC5875] to
      alert a user agent of changes made by someone else to their
      provisioned data.

   RFC 4826, Extensible Markup Language (XML) Formats for Representing
      Resource Lists (S):  [RFC4826] defines two XML document formats
      used to represent buddy lists.  One is simply a list of users (or
      more generally, resources), and the other defines a buddy list
      whose membership is composed of a list of users or resources.
      These lists can be manipulated by XCAP, allowing a user to add or
      remove members from their buddy lists.  The buddy list is also

Rosenberg                     Informational                     [Page 7]
RFC 6914                   Simple Made Simple                 April 2013

      accessed by the resource list server specified in RFC 4662 for
      processing resource list subscriptions.

   RFC 4827, An Extensible Markup Language (XML) Configuration Access
      Protocol (XCAP) Usage for Manipulating Presence Document Contents
      (S):  [RFC4827] defines an XCAP usage that allows a user to store
      an "offline" presence document.  This is a presence status that is
      used by a presence server when there are no presence documents
      published for that user by any user agents currently running.

2.5.  Federation

   Federation refers to the interconnection of different presence and
   instant messaging systems for the purposes of communications.
   Federation can be between domains or within a domain.  A document has
   been developed that describes how presence and IM federation works.

   RFC 5344, Presence and Instant Messaging Peering Use Cases (I):
      [RFC5344] describes a basic set of presence and instant messaging
      use cases for federating between providers.

2.6.  Optimizations

   When running over wireless links, presence can be a very expensive
   service.  Notifications often get sent when the change is not really
   relevant to the watcher.  Furthermore, when a notification is sent,
   it contains the full presence state of the watcher, rather than just
   an indication of what changed.  Optimizations have been defined to
   address both of these cases.

   RFC 4660, Functional Description of Event Notification Filtering
      (S):  [RFC4660] defines a mechanism that allows a watcher to
      include filters in its subscription.  These filters limit the
      cases in which notifications are sent.  It is used in conjunction
      with RFC 4661, which specifies the XML format of the filters
      themselves.  The mechanism, though targeted for presence, can be
      applied to any SIP event package.

   RFC 4661, An Extensible Markup Language (XML)-Based Format for Event
      Notification Filtering (S):  [RFC4661] defines an XML format used
      with the event notification filtering mechanism defined in RFC
      4660 [RFC4660].

   RFC 5262, Presence Information Data Format (PIDF)  Extension for
      Partial Presence (S):  [RFC5262] defines a new XML format for
      representing changes in presence documents, called a partial PIDF
      document.  This format contains an XML patch operation [RFC5261]
      that, when applied to the previous presence document, yields the

Rosenberg                     Informational                     [Page 8]
RFC 6914                   Simple Made Simple                 April 2013

      new presence document.  The partial PIDF document is included in
      presence notifications when a watcher indicates that they support
      the format.

   RFC 5263, Session Initiation Protocol (SIP) Extension for Partial
      Notification of Presence Information (S):  [RFC5263] defines a
      mechanism for receiving notifications that contain partial
      presence documents.

   RFC 5264, Publication of Partial Presence Information (S):  [RFC5264]
      defines a mechanism for publishing presence status using a partial
      PIDF document.

   RFC 5261, An Extensible Markup Language (XML) Patch Operations
      Framework Utilizing XML Path Language (XPath) Selectors (S):
      [RFC5261] defines an XML structure for representing changes in XML
      documents.  It is a form of "diff" but specifically for XML
      documents.  It is used by several of the optimization mechanisms
      defined for SIMPLE.

   RFC 5112, The Presence-Specific Static Dictionary for Signaling
      Compression (Sigcomp) (S):  [RFC5112] defines a dictionary for
      usage with Signaling Compression (Sigcomp) [RFC3320] to improve
      the compressibility of presence documents.

   RFC 6446, Session Initiation Protocol (SIP) Event Notification
      Extension for Notification Rate Control (S):  [RFC6446] specifies
      mechanisms for adjusting the rate of SIP event notifications.
      These mechanisms can be applied in subscriptions to all SIP event
      packages.

3.  Instant Messaging

   SIMPLE defines two modes of instant messaging.  These are page mode
   and session mode.  In page mode, instant messages are sent by sending
   a SIP request that contains the contents of the instant message.  In
   session mode, IM is viewed as another media type -- along with audio
   and video -- and an INVITE request is used to set up a session that
   includes IM as a media type.  While page mode is more efficient for
   one or two message conversations, session mode is more efficient for
   longer conversations since the messages are not sent through the SIP
   servers.  Furthermore, by viewing IM as a media type, all of the
   features available in SIP signaling -- third party call control,
   forking, and so on, are available for IM.

Rosenberg                     Informational                     [Page 9]
RFC 6914                   Simple Made Simple                 April 2013

3.1.  Page Mode

   RFC 3428, Session Initiation Protocol (SIP) Extension for Instant
      Messaging (S):  [RFC3428] introduces the MESSAGE method, which can
      be used to send an instant message through SIP signaling.

   RFC 5365, Multiple-Recipient MESSAGE Requests in the Session
      Initiation Protocol (SIP) (S):  [RFC5365] defines a mechanism
      whereby a client can send a single SIP MESSAGE to multiple
      recipients.  This is accomplished by including the list of
      recipients as an object in the body and having a network server
      send a copy to each recipient.

3.2.  Session Mode

   RFC 4975, The Message Session Relay Protocol (MSRP) (S):  [RFC4975]
      defines a small text-based protocol for exchanging arbitrarily
      sized content of any kind between users.  An MSRP session is set
      up by exchanging certain information, such as an MSRP URI, within
      SIP and Session Description Protocol (SDP) signaling.

   RFC 3862, Common Presence and Instant Messaging (CPIM): Message
      Format (S):  [RFC3862] defines a wrapper around instant message
      content providing metadata, such as the sender and recipient
      identity.  The CPIM format is carried in MSRP.

   RFC 4976, Relay Extensions for the Message Sessions Relay Protocol
      (MSRP) (S):  [RFC4976] adds support for relays to MSRP.  These
      relay servers receive MSRP messages and send them towards the
      destination.  They provide support for firewall and NAT traversal
      and allow for features such as recording and inspection to be
      implemented.

   RFC 6135, An Alternative Connection Model for the Message Session
      Relay Protocol (MSRP) (S):  [RFC6135] allows clients to negotiate
      which endpoint in a session will establish the MSRP connection.
      Without this specification, the client generating the SDP offer
      would initiate the connection.

   RFC 6714, Connection Establishment for Media Anchoring (CEMA) for the
      Message Session Relay Protocol (MSRP) (S):  [RFC6714] allows
      middleboxes to anchor the MSRP connection, without the need for
      middleboxes to modify the MSRP messages; thus, it also enables a
      secure end-to-end MSRP communication in networks where such
      middleboxes are deployed.

Rosenberg                     Informational                    [Page 10]
RFC 6914                   Simple Made Simple                 April 2013

3.3.  IM Chat Rooms

   In SIMPLE, IM multi-user chat (also known as chat-rooms) are provided
   using regular SIP conferencing mechanisms.  The framework for SIP
   conferencing [RFC4353] and conference control [RFC5239] describe how
   all SIP-based conferencing works; including joining and leaving,
   persistent and temporary conferences, floor control and moderation,
   and learning of conference membership, amongst other functions.  All
   that is necessary are extensions to provide features that are
   specific to IM.

   Multi-party Chat Using the Message Session Relay Protocol (MSRP)
      (Work in Progress):  [SIMPCHAT] defines how MSRP is used to
      provide support for nicknames and private chat within an IM
      conference.

3.4.  IM Features

   Several specifications have been written to provide IM-specific
   features for SIMPLE.  These include "is-typing" indications, allowing
   a user to know when their messaging peer is composing a response and
   allowing a user to know when their IM has been received via delivery
   notifications.

   RFC 3994, Indication of Message Composition for Instant Messaging
      (S):  [RFC3994] defines an XML format that can be sent in instant
      messages that indicates the status of message composition.  This
      provides the familiar "is-typing" indication in IM systems, but
      also supports voice, video, and other message types.

   RFC 5438, Instant Message Disposition Notification (IMDN) (S):
      [RFC5438] provides delivery notifications of IM receipt.  This
      allows a user to know with certainty that a message has been
      received.

4.  Security Considerations

   This specification is an overview of existing specifications and does
   not introduce any security considerations on its own.

5.  Acknowledgements

   Thanks to Vijay Gurbani, Barry Leiba, Stephen Hanna, and Salvatore
   Loreto for their review and comments.

Rosenberg                     Informational                    [Page 11]
RFC 6914                   Simple Made Simple                 April 2013

6.  Informative References

   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
               3", BCP 9, RFC 2026, October 1996.

   [RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
               A., Peterson, J., Sparks, R., Handley, M., and E.
               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
               June 2002.

   [RFC3265]   Roach, A., "Session Initiation Protocol (SIP)-Specific
               Event Notification", RFC 3265, June 2002.

   [RFC3320]   Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
               Liu, Z., and J. Rosenberg, "Signaling Compression
               (SigComp)", RFC 3320, January 2003.

   [RFC3428]   Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema,
               C., and D. Gurle, "Session Initiation Protocol (SIP)
               Extension for Instant Messaging", RFC 3428,
               December 2002.

   [RFC3856]   Rosenberg, J., "A Presence Event Package for the Session
               Initiation Protocol (SIP)", RFC 3856, August 2004.

   [RFC3857]   Rosenberg, J., "A Watcher Information Event Template-
               Package for the Session Initiation Protocol (SIP)",
               RFC 3857, August 2004.

   [RFC3858]   Rosenberg, J., "An Extensible Markup Language (XML) Based
               Format for Watcher Information", RFC 3858, August 2004.

   [RFC3862]   Klyne, G. and D. Atkins, "Common Presence and Instant
               Messaging (CPIM): Message Format", RFC 3862, August 2004.

   [RFC3863]   Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
               W., and J. Peterson, "Presence Information Data Format
               (PIDF)", RFC 3863, August 2004.

   [RFC3903]   Niemi, A., "Session Initiation Protocol (SIP) Extension
               for Event State Publication", RFC 3903, October 2004.

   [RFC3994]   Schulzrinne, H., "Indication of Message Composition for
               Instant Messaging", RFC 3994, January 2005.

   [RFC4353]   Rosenberg, J., "A Framework for Conferencing with the
               Session Initiation Protocol (SIP)", RFC 4353,
               February 2006.

Rosenberg                     Informational                    [Page 12]
RFC 6914                   Simple Made Simple                 April 2013

   [RFC4479]   Rosenberg, J., "A Data Model for Presence", RFC 4479,
               July 2006.

   [RFC4480]   Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
               Rosenberg, "RPID: Rich Presence Extensions to the
               Presence Information Data Format (PIDF)", RFC 4480,
               July 2006.

   [RFC4481]   Schulzrinne, H., "Timed Presence Extensions to the
               Presence Information Data Format (PIDF) to Indicate
               Status Information for Past and Future Time Intervals",
               RFC 4481, July 2006.

   [RFC4482]   Schulzrinne, H., "CIPID: Contact Information for the
               Presence Information Data Format", RFC 4482, July 2006.

   [RFC4660]   Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
               Requena, "Functional Description of Event Notification
               Filtering", RFC 4660, September 2006.

   [RFC4661]   Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
               Requena, "An Extensible Markup Language (XML)-Based
               Format for Event Notification Filtering", RFC 4661,
               September 2006.

   [RFC4662]   Roach, A., Campbell, B., and J. Rosenberg, "A Session
               Initiation Protocol (SIP) Event Notification Extension
               for Resource Lists", RFC 4662, August 2006.

   [RFC4745]   Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
               Polk, J., and J. Rosenberg, "Common Policy: A Document
               Format for Expressing Privacy Preferences", RFC 4745,
               February 2007.

   [RFC4825]   Rosenberg, J., "The Extensible Markup Language (XML)
               Configuration Access Protocol (XCAP)", RFC 4825,
               May 2007.

   [RFC4826]   Rosenberg, J., "Extensible Markup Language (XML) Formats
               for Representing Resource Lists", RFC 4826, May 2007.

   [RFC4827]   Isomaki, M. and E. Leppanen, "An Extensible Markup
               Language (XML) Configuration Access Protocol (XCAP) Usage
               for Manipulating Presence Document Contents", RFC 4827,
               May 2007.

   [RFC4975]   Campbell, B., Mahy, R., and C. Jennings, "The Message
               Session Relay Protocol (MSRP)", RFC 4975, September 2007.

Rosenberg                     Informational                    [Page 13]
RFC 6914                   Simple Made Simple                 April 2013

   [RFC4976]   Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
               for the Message Sessions Relay Protocol (MSRP)",
               RFC 4976, September 2007.

   [RFC5025]   Rosenberg, J., "Presence Authorization Rules", RFC 5025,
               December 2007.

   [RFC5112]   Garcia-Martin, M., "The Presence-Specific Static
               Dictionary for Signaling Compression (Sigcomp)",
               RFC 5112, January 2008.

   [RFC5196]   Lonnfors, M. and K. Kiss, "Session Initiation Protocol
               (SIP) User Agent Capability Extension to Presence
               Information Data Format (PIDF)", RFC 5196,
               September 2008.

   [RFC5239]   Barnes, M., Boulton, C., and O. Levin, "A Framework for
               Centralized Conferencing", RFC 5239, June 2008.

   [RFC5261]   Urpalainen, J., "An Extensible Markup Language (XML)
               Patch Operations Framework Utilizing XML Path Language
               (XPath) Selectors", RFC 5261, September 2008.

   [RFC5262]   Lonnfors, M., Leppanen, E., Khartabil, H., and J.
               Urpalainen, "Presence Information Data Format (PIDF)
               Extension for Partial Presence", RFC 5262,
               September 2008.

   [RFC5263]   Lonnfors, M., Costa-Requena, J., Leppanen, E., and H.
               Khartabil, "Session Initiation Protocol (SIP) Extension
               for Partial Notification of Presence Information",
               RFC 5263, September 2008.

   [RFC5264]   Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of
               Partial Presence Information", RFC 5264, September 2008.

   [RFC5344]   Houri, A., Aoki, E., and S. Parameswar, "Presence and
               Instant Messaging Peering Use Cases", RFC 5344,
               October 2008.

   [RFC5365]   Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
               MESSAGE Requests in the Session Initiation Protocol
               (SIP)", RFC 5365, October 2008.

   [RFC5367]   Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
               Request-Contained Resource Lists in the Session
               Initiation Protocol (SIP)", RFC 5367, October 2008.

Rosenberg                     Informational                    [Page 14]
RFC 6914                   Simple Made Simple                 April 2013

   [RFC5438]   Burger, E. and H. Khartabil, "Instant Message Disposition
               Notification (IMDN)", RFC 5438, February 2009.

   [RFC5874]   Rosenberg, J. and J. Urpalainen, "An Extensible Markup
               Language (XML) Document Format for Indicating a Change in
               XML Configuration Access Protocol (XCAP) Resources",
               RFC 5874, May 2010.

   [RFC5875]   Urpalainen, J. and D. Willis, "An Extensible Markup
               Language (XML) Configuration Access Protocol (XCAP) Diff
               Event Package", RFC 5875, May 2010.

   [RFC6135]   Holmberg, C. and S. Blau, "An Alternative Connection
               Model for the Message Session Relay Protocol (MSRP)",
               RFC 6135, February 2011.

   [RFC6446]   Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
               Protocol (SIP) Event Notification Extension for
               Notification Rate Control", RFC 6446, January 2012.

   [RFC6665]   Roach, A., "SIP-Specific Event Notification", RFC 6665,
               July 2012.

   [RFC6714]   Holmberg, C., Blau, S., and E. Burger, "Connection
               Establishment for Media Anchoring (CEMA) for the Message
               Session Relay Protocol (MSRP)", RFC 6714, August 2012.

   [SIMPCHAT]  Niemi, A., Garcia, M., and G. Sandbakken, "Multi-party
               Chat Using the Message Session Relay Protocol (MSRP)",
               Work in Progress, January 2013.

Author's Address

   Jonathan Rosenberg
   jdrosen.net

   EMail: jdrosen@jdrosen.net
   URI:   http://www.jdrosen.net

Rosenberg                     Informational                    [Page 15]