\section{Introduction}

The PIDF definition \citenorm{draft-ietf-impp-cpim-pidf} describes a
basic presence information data format for exchanging presence
information in CPIM-compliant systems.  It consists of a
\xmlelement{presence} root element, zero or more \xmlelement{tuple}
elements carrying presence information, zero or more \xmlelement{note}
elements and zero or more extension elements from other name spaces. 
Each tuple defines a basic status of either ``open'' or ``closed''.

This document provides additional status information for presentities
and defines a \emph{Rich Presence Information Data Format for Presence}
(RPID) to convey this information. 

This extension has three main goals:

\begin{enumerate}
\item Provide rich presence indication that is at least as powerful as
common commercial presence systems.  Such feature-parity simplifies
transition to CPIM-compliant systems, both in terms of user acceptance
and protocol conversion.

\item Maintain backwards-compatibility with PIDF, so that PIDF-only
watchers and gateways can continue to function properly, naturally
without access to the functionality described here.

\end{enumerate}

We make no assumptions how the information in the RPID is generated. 
Experience has shown that users are not always diligent about updating
their presence status.  Thus, we want to make it as easy as possible to
derive RPID information from other information sources, such as
calendars, the status of communication devices such as telephones,
typing activity and physical presence detectors as commonly found in
energy-management systems.

The information in a presence document can be generated by a single
entity or can be composed from information published by multiple
entities.

Many of the elements correspond to data commonly found in personal
calendars.  Thus, we attempted to align some of the extensions with the
usage found in calendar formats such as iCal \citeinform{rfc2445} and
xCal \citeinform{draft-ietf-calsch-many-xcal}, as noted below.

Note that PIDF documents and this extension can be used in two different
contexts, namely by the presentity to publish its presence status and by
the presence server to notify some set of watchers.  The presence server
{\MAY} compose, translate or filter the published presence state before
delivering customized presence information to the watcher.  For example,
it may merge presence information from multiple PUAs, remove whole
elements, translate values in elements or remove information from
elements.  Mechanisms that filter calls and other communications to the
presentity can subscribe to this presence information just like a
regular watcher and in turn generate automated rules, such as scripts
\citeinform{draft-ietf-iptel-cpl}, that govern the actual communications
behavior of the presentity.

The flow diagram below illustrates this process.

\begin{verbatim}
presentity 
   |
   --> publish 
         |
         --> PA (filter) 
                 --> notification 1 to A, B, C
                 --> notification 2 to D, E
                 --> notification 3 to F
                 --> notification 4 to script gen.
\end{verbatim}
