RFC 3859 (rfc3859) - Page 2 of 15

Common Profile for Presence (CPP)

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 RFC 2778 [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