Network Working Group                                        J. Peterson
Request for Comments: 3859                                       NeuStar
Category: Standards Track                                    August 2004


                   Common Profile for Presence (CPP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Abstract Presence Service  . . . . . . . . . . . . . . . . . .  4
       3.1.  Overview of the Presence Service . . . . . . . . . . . .  4
       3.2.  Identification of PRESENTITIES and WATCHERS  . . . . . .  6
             3.2.1.  Address Resolution . . . . . . . . . . . . . . .  6
       3.3.  Format of Presence Information . . . . . . . . . . . . .  6
       3.4.  The Presence Service . . . . . . . . . . . . . . . . . .  7
             3.4.1.  The Subscribe Operation  . . . . . . . . . . . .  7
             3.4.2.  The Notify Operation . . . . . . . . . . . . . .  8
             3.4.3.  Subscribe Operation (with Zero Duration) . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
       5.1.  The PRES URI Scheme  . . . . . . . . . . . . . . . . . .  9
   6.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       7.1.  Normative References . . . . . . . . . . . . . . . . . . 10
       7.2.  Informative References . . . . . . . . . . . . . . . . . 11



Peterson                    Standards Track                     [Page 1]

RFC 3859              Common Profile for Presence            August 2004


   A.  PRES URI IANA Registration Template  . . . . . . . . . . . . . 12
       A.1.  URI Scheme Name  . . . . . . . . . . . . . . . . . . . . 12
       A.2.  URI Scheme Syntax  . . . . . . . . . . . . . . . . . . . 12
       A.3.  Character Encoding Considerations  . . . . . . . . . . . 12
       A.4.  Intended Usage . . . . . . . . . . . . . . . . . . . . . 12
       A.5.  Applications and/or Protocols which use this URI Scheme
             Name . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       A.6.  Interoperability Considerations  . . . . . . . . . . . . 13
       A.7.  Security Considerations  . . . . . . . . . . . . . . . . 13
       A.8.  Relevant Publications  . . . . . . . . . . . . . . . . . 13
       A.9.  Person & Email Address to Contact for Further
             Information. . . . . . . . . . . . . . . . . . . . . . . 13
       A.10. Author/Change Controller . . . . . . . . . . . . . . . . 13
       A.11. Applications and/or Protocols which use this URI Scheme
             Name . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   B.  Issues of Interest . . . . . . . . . . . . . . . . . . . . . . 13
       B.1.  Address Mapping  . . . . . . . . . . . . . . . . . . . . 13
       B.2.  Source-Route Mapping . . . . . . . . . . . . . . . . . . 13
   C.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15

1.  Introduction

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

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

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



Peterson                    Standards Track                     [Page 2]

RFC 3859              Common Profile for Presence            August 2004


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

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.

   This memos makes use of the vocabulary defined in RFC 2778 [5].
   Terms such as CLOSED, INSTANT INBOX, PRESENCE, and OPEN are used in
   the same meaning as defined therein.

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

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

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




Peterson                    Standards Track                     [Page 3]

RFC 3859              Common Profile for Presence            August 2004


3.  Abstract Presence Service

3.1.  Overview of the Presence Service

   When an application wants to subscriber to the presence information
   associated with a PRESENTITY (in order to receive periodic
   notifications of presence information), it invokes the subscribe
   operation, e.g.,

             +-------+                    +-------+
             |       |                    |       |
             | appl. | -- subscribe ----> | pres. |
             |       |                    | svc.  |
             +-------+                    +-------+

   The subscribe operation has the following attributes: watcher,
   target, duration, SubscriptID and TransID.  The 'watcher' and
   'target' identify the WATCHER and PRESENTITY, respectively, using the
   identifiers described in Section 3.2.  The duration specifies the
   maximum number of seconds that the SUBSCRIPTION should be active
   (which may be zero, in which case this is a one-time request for
   presence information).  The SubscriptID creates a reference to the
   SUBSCRIPTION that is used when unsubscribing.  The TransID is a
   unique identifier used to correlate the subscribe operation with a
   response operation.  Gateways should be capable of handling TransIDs
   and SubscriptIDs up to 40 bytes in length.

   Upon receiving a subscribe operation, the service immediately
   responds by invoking the response operation containing the same
   TransID, e.g.,

             +-------+                    +-------+
             |       |                    |       |
             | appl. | <----- response -- | pres. |
             |       |                    | svc.  |
             +-------+                    +-------+

   The response operation has the following attributes: status, TransID,
   and duration.  'status' indicates whether the subscribe operation has
   succeeded or failed.  The TransID of the response operation
   corresponds to the TransID of the subscription operation to which it
   is responding.  The 'duration' attribute specifies the number of
   seconds for which the subscription will be active (which may differ
   from the value requested in the subscribe operation).







Peterson                    Standards Track                     [Page 4]

RFC 3859              Common Profile for Presence            August 2004


   If the response operation indicates success, the service immediately
   invokes the notify operation to communicate the presence information
   to the WATCHER, e.g.,

             +-------+                    +-------+
             |       |                    |       |
             | appl. | <------- notify -- | pres. |
             |       |                    | svc.  |
             +-------+                    +-------+

   The notify operation has the following attributes: watcher, target,
   and TransID.  The values of 'watcher' and 'target' are identical to
   those given in the subscribe operation that triggered this notify
   operation.  The TransID is a unique identifier for this notification.

   The notify operation also has content, namely PRESENCE INFORMATION.
   Content details are specified in Section 3.3.

   If the duration parameter is non-zero, then for up to the specified
   duration, the service invokes the notify operation whenever there are
   any changes to the PRESENTITY's presence information.  Otherwise,
   exactly one notify operation is invoked, achieving a one-time poll of
   the presence information.  Regardless, there is no application
   response to the notify operation (i.e., the application does not
   invoke a response operation when a notify operation occurs) defined
   in CPP.

   The application may prematurely cancel a subscription by re-invoking
   the subscribe operation (as described above) with a duration of 0 and
   the same SubscriptID as the original subscribe operation , e.g.,

             +-------+                    +-------+
             |       |                    |       |
             | appl. | -- subscribe 0 --> | pres. |
             |       |                    | svc.  |
             +-------+                    +-------+

   Note that a notify operation will be invoked when a subscription is
   prematurely canceled in this fashion; this notification may be
   discarded by the watcher.











Peterson                    Standards Track                     [Page 5]