SIMPLE                                                      J. Rosenberg
Internet-Draft                                                     Cisco
Intended status: Informational                              July 9, 2008
Expires: January 10, 2009


 SIMPLE made Simple: An Overview of the IETF Specifications for Instant
   Messaging and Presence using the Session Initiation Protocol (SIP)
                      draft-ietf-simple-simple-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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 SIMPLE - SIP for
   Instant Messaging and Presence Leveraging Extensions.  This document
   serves as a guide to the SIMPLE suite of specifications.  It breaks
   them up into categories and explains what each is for and how they
   relate to each other.



Rosenberg               Expires January 10, 2009                [Page 1]


Internet-Draft             Simple Made Simple                  July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   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  . . . . . . . . . . . . . . . . . . . . . .  9
   3.  Instant Messaging  . . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  Page Mode  . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Session Mode . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  IM Chat Rooms  . . . . . . . . . . . . . . . . . . . . . . 11
     3.4.  IM Features  . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17































Rosenberg               Expires January 10, 2009                [Page 2]


Internet-Draft             Simple Made Simple                  July 2008


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 SIMPLE -
   SIP for Instant Messaging and Presence Leveraging Extensions.  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 exactly SIMPLE is, what
   specifications cover it, what functionality it provides, and how
   these specifications relate to each other.

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

   S: Standards Track (Proposed Standard, Draft Standard, or Standard)

   E: Experimental

   B: Best Current Practice

   I: Informational


2.  Presence

   SIMPLE provides for both presence and 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





Rosenberg               Expires January 10, 2009                [Page 3]


Internet-Draft             Simple Made Simple                  July 2008


   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

2.1.  Core Protocol Machinery

   RFC 3265, SIP-Specific Event Notification (S):  RFC 3265 [RFC3265]
      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 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 SIP (S):  RFC 3856 [RFC3856]
      defines an event package for indicating user presence through SIP.
      Through this package, a SIP user agent can ask to be notified of
      the presence state of a presentity (presence entity).  The content
      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):  RFC 4662 [RFC4662] defines an
      extension to RFC 3265 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.

   draft-ietf-sip-uri-list-subscribe, Subscriptions to Request-Contained
   Resource Lists in the Session Initiation Protocol (SIP) (S):
      [I-D.ietf-sip-uri-list-subscribe] 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



Rosenberg               Expires January 10, 2009                [Page 4]


Internet-Draft             Simple Made Simple                  July 2008


      provisioned ahead of time on the server.

   RFC 3903, SIP Extension for Event State Publication (S):  RFC 3903
      [RFC3903] defines the PUBLISH method.  With this method, a user
      agent 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.

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) which 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 (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 devices and
      person status, and explains how these relate to each other.  It
      describes how presence documents are used to represent states in
      communications systems 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 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 a user is idle or not.

   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 additional 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 2pm to 3pm, 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



Rosenberg               Expires January 10, 2009                [Page 5]


Internet-Draft             Simple Made Simple                  July 2008


      name).

   draft-ietf-simple-prescaps-ext, Session Initiation Protocol (SIP)
   User Agent  Capability Extension to Presence Information Data Format
   (PIDF) (S):  [I-D.ietf-simple-prescaps-ext] adds even more attributes
      to the presence document schema, this time to allow indication of
      capabilities for the user 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 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.






Rosenberg               Expires January 10, 2009                [Page 6]


Internet-Draft             Simple Made Simple                  July 2008


   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.

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 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.  XCAP is 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.

   draft-ietf-sip-xcapevent, An Extensible Markup Language (XML)
   Configuration Access Protocol (XCAP) Diff Event Package (S):
      [I-D.ietf-sip-xcapevent] 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.

   draft-ietf-simple-xcap-diff, An Extensible Markup Language (XML)
   Document Format for Indicating A Change in XML Configuration Access
   Protocol (XCAP) Resources (S):  [I-D.ietf-simple-xcap-diff] defines
      an XML format for indicating changes in XCAP documents.  It makes
      use of an XML diff format defined in
      [I-D.ietf-simple-xml-patch-ops].  It is used in conjunction with
      [I-D.ietf-sip-xcapevent] to alert a user agent of changes made by
      someone else to their provisioned data.






Rosenberg               Expires January 10, 2009                [Page 7]


Internet-Draft             Simple Made Simple                  July 2008


   RFC 4826, 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 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.  Documents have
   been developed which describe how presence and IM federation works,
   the scale of those systems have been analyzed, and optimizations have
   been defined to improve on that scale.

   draft-ietf-speermint-consolidated-presence-im-usecases, Presence &
   Instant Messaging Peering Use Cases (I):
      [I-D.ietf-speermint-consolidated-presence-im-usecases] describes a
      basic set of presence and instant messaging use cases for
      federating between providers.

   draft-ietf-simple-interdomain-scaling-analysis, Presence Interdomain
   Scaling Analysis for SIP/SIMPLE (I):
      [I-D.ietf-simple-interdomain-scaling-analysis] describes several
      different examples of federated domains, and for each, provides a
      numerical analysis on the volume of presence and IM traffic that
      can be expected.

   draft-ietf-simple-intradomain-federation, Models for Intra-Domain
   Presence Federation (I):  , [I-D.ietf-simple-intradomain-federation]
      describes several different models for federating presence systems
      within a domain.  Example use cases are described, along with
      considerations for routing, policy, and presence state.







Rosenberg               Expires January 10, 2009                [Page 8]


Internet-Draft             Simple Made Simple                  July 2008


   draft-ietf-simple-view-sharing, Optimizing Federated Presence with
   View Sharing (S):  , [I-D.ietf-simple-view-sharing] defines an
      enhancement to [RFC3265] called view sharing, used in federated
      domains.  With this optimization, a single document is sent from
      watched domain to watching domain when there are multiple watchers
      who would receive the same document otherwise.

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 [RFC4661] 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].

   draft-ietf-simple-partial-pidf-format, Presence Information Data
   format (PIDF)  Extension for Partial Presence (S):
      [I-D.ietf-simple-partial-pidf-format] defines a new XML format for
      representing changes in presence documents, called a partial PIDF
      document.  This format contains an XML patch operation
      [I-D.ietf-simple-xml-patch-ops], that, when applied to the
      previous presence document, yields the new presence document.  The
      partial PIDF document is included in presence notifications when a
      watcher indicates that they support the format.

   draft-ietf-simple-partial-publish, Publication of Partial Presence
   Information (S):  [I-D.ietf-simple-partial-publish] defines a
      mechanism for publishing presence status using a partial PIDF
      document.

   draft-ietf-simple-xml-patch-ops, An Extensible Markup Language (XML)
   Patch  Operations Framework Utilizing XML Path Language (XPath)
   Selectors (S):  [I-D.ietf-simple-xml-patch-ops] defines an XML
      structure for representing changes in XML documents.  It is a form



Rosenberg               Expires January 10, 2009                [Page 9]


Internet-Draft             Simple Made Simple                  July 2008


      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
      compressability of presence documents.


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.

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.

   draft-ietf-sip-uri-list-message, Multiple-Recipient MESSAGE Requests
   in the  Session Initiation Protocol (SIP) (S):
      [I-D.ietf-sip-uri-list-message] 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 time between users.  An MSRP session is set
      up by exchanging certain information, such as an MSRP URI, within
      SIP and SDP signaling.







Rosenberg               Expires January 10, 2009               [Page 10]


Internet-Draft             Simple Made Simple                  July 2008


   RFC 3862, Common Presence and Instant Messaging (CPIM): Message
   Format (S):  [RFC3862] defines a wrapper around instant message
      content, providing meta-data 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.

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
   [I-D.ietf-xcon-framework] 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.

   draft-ietf-simple-chat, Multi-party Instant Message (IM) Sessions
   the Message Session Relay Protocol (MSRP) (S):
      [I-D.ietf-simple-chat] 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
   delivery notifications, allowing a user to know when their IM has
   been received.

   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.

   draft-ietf-simple-imdn, Instant Message Disposition Notification
   (S):  [I-D.ietf-simple-imdn] provides delivery notifications of IM
      receipt.  This allows a user to know with certainty that a message
      has been received.





Rosenberg               Expires January 10, 2009               [Page 11]


Internet-Draft             Simple Made Simple                  July 2008


4.  Security Considerations

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


5.  IANA Considerations

   None.


6.  Informative References

   [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.

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

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

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

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

   [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



Rosenberg               Expires January 10, 2009               [Page 12]


Internet-Draft             Simple Made Simple                  July 2008


              Presence Information Data Format", RFC 4482, July 2006.

   [I-D.ietf-simple-prescaps-ext]
              Lonnfors, M. and K. Kiss, "Session Initiation Protocol
              (SIP) User Agent Capability Extension to  Presence
              Information Data Format (PIDF)",
              draft-ietf-simple-prescaps-ext-10 (work in progress),
              May 2008.

   [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.

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

   [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.

   [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.

   [I-D.ietf-sip-xcapevent]
              Urpalainen, J., "An Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)  Diff Event Package",
              draft-ietf-sip-xcapevent-03 (work in progress), May 2008.

   [I-D.ietf-simple-xcap-diff]
              Rosenberg, J. and J. Urpalainen, "An Extensible Markup
              Language (XML) Document Format for Indicating A Change  in
              XML Configuration Access Protocol (XCAP) Resources",
              draft-ietf-simple-xcap-diff-09 (work in progress),
              May 2008.

   [I-D.ietf-simple-xml-patch-ops]



Rosenberg               Expires January 10, 2009               [Page 13]


Internet-Draft             Simple Made Simple                  July 2008


              Urpalainen, J., "An Extensible Markup Language (XML) Patch
              Operations Framework Utilizing XML  Path Language (XPath)
              Selectors", draft-ietf-simple-xml-patch-ops-04 (work in
              progress), November 2007.

   [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.

   [I-D.ietf-simple-partial-publish]
              Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of
              Partial Presence Information",
              draft-ietf-simple-partial-publish-07 (work in progress),
              February 2008.

   [I-D.ietf-simple-partial-pidf-format]
              Lonnfors, M., Leppanen, E., Khartabil, H., and J.
              Urpalainen, "Presence Information Data format (PIDF)
              Extension for Partial Presence",
              draft-ietf-simple-partial-pidf-format-10 (work in
              progress), November 2007.

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

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

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

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

   [I-D.ietf-xcon-framework]
              Barnes, M., Boulton, C., and O. Levin, "A Framework for
              Centralized Conferencing", draft-ietf-xcon-framework-11
              (work in progress), April 2008.

   [I-D.ietf-simple-chat]



Rosenberg               Expires January 10, 2009               [Page 14]


Internet-Draft             Simple Made Simple                  July 2008


              Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-
              party Instant Message (IM) Sessions Using the Message
              Session Relay  Protocol (MSRP)", draft-ietf-simple-chat-02
              (work in progress), February 2008.

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

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

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

   [I-D.ietf-simple-imdn]
              Burger, E. and H. Khartabil, "Instant Message Disposition
              Notification", draft-ietf-simple-imdn-07 (work in
              progress), April 2008.

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

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

   [I-D.ietf-sip-uri-list-message]
              Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
              MESSAGE Requests in the Session Initiation Protocol
              (SIP)", draft-ietf-sip-uri-list-message-03 (work in
              progress), December 2007.

   [I-D.ietf-speermint-consolidated-presence-im-usecases]
              Houri, A., "Presence & Instant Messaging Peering Use
              Cases",
              draft-ietf-speermint-consolidated-presence-im-usecases-04
              (work in progress), February 2008.

   [I-D.ietf-simple-interdomain-scaling-analysis]
              Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V.,
              and H. Schulzrinne, "Presence Interdomain Scaling Analysis
              for SIP/SIMPLE",
              draft-ietf-simple-interdomain-scaling-analysis-04 (work in
              progress), February 2008.

   [I-D.ietf-simple-intradomain-federation]
              Rosenberg, J. and A. Houri, "Models for Intra-Domain



Rosenberg               Expires January 10, 2009               [Page 15]


Internet-Draft             Simple Made Simple                  July 2008


              Presence Federation",
              draft-ietf-simple-intradomain-federation-00 (work in
              progress), February 2008.

   [I-D.ietf-simple-view-sharing]
              Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing
              Federated Presence with View Sharing",
              draft-ietf-simple-view-sharing-00 (work in progress),
              February 2008.

   [I-D.ietf-sip-uri-list-subscribe]
              Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
              Request-Contained Resource Lists in the Session Initiation
              Protocol (SIP)", draft-ietf-sip-uri-list-subscribe-02
              (work in progress), November 2007.


Author's Address

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net
























Rosenberg               Expires January 10, 2009               [Page 16]


Internet-Draft             Simple Made Simple                  July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Rosenberg               Expires January 10, 2009               [Page 17]