RFC 3859 (rfc3859) - Page 2 of 15
Common Profile for Presence (CPP)
Alternative Format: Original Text Document
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