  <xs:complexType name="members">
    <xs:sequence>
      <xs:any namespace="pidf" processContents="lax" minOccurs="0"
         maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:simpleType name="contact-type">
    <xs:restriction base="xs:string">
       <xs:enumeration value="individual"/>
       <xs:enumeration value="device"/>
       <xs:enumeration value="group"/>
    </xs:restriction>
  </xs:simpleType>

There are many styles of publishing reachability information.  Some
principals may publish only one SIP address, for example, and leave it
to the interaction of caller preferences and callee policy to reach the
right destination.  Others may publish contact information for each
device, indicating the preferences and capabilities of each.  A hybrid
solution advertises many difference capabilities, but associated with a
smaller number of device contact address.

\item Caller preferences \citeinform{callerprefs} allows the callee to
indicate whether a device has a recording device such as an answering
machine or a ``robot'' such as an IVR system with automated
announcements [TBD check details].  Thus, we offer three
classifications:  ``live'', ``robot'' (TBD:  or autoanswer?) and
``recorder''.  A single contact can have any combination of properties. 
For example, a voice terminal with ``live'' and ``robot'' capabilities
could indicate that the user may pick up or let voicemail handle the
call. 

(We will revisit this classification once robots pass the Turing test. 
This will likely occur before this document reaches Draft Standard
status, if history is a guide.)

\subsection{Device Type}
\label{sec:devicetype}

The \xmlelement{devicetype} element describes the type of device
represented by the tuple and only applies if the \xmlelement{class} is a
``device''.  The device type can be drawn from the list below or can be
free text.  Additional device types can be registered with IANA
(Section~\ref{sec:iana}).

\begin{description}
\item[PC:] A workstation, PC, laptop or similar device.

\item[Mobile:] A mobile device, such as a cellphone.

\item[Phone:] A classical analog or digital telephone. 
\end{description}

  <xs:element name="devicetype" type="xs:token"/>

\subsection{Availability}
\label{sec:availability}

The basic status value of OPEN can be qualified by an availability
indication.  It can take non-negative integer values and indicates how
many additional conversations of that type the device or the person
using the device can handle at this time.

\motivation{The availability appears to be primarily useful for routing
text-based conversations in call centers.  This indication appears to be
more practically meaningful than a fractional indication.}

\subsection{Location Element}
\label{sec:location}

Location information can take five forms:

\begin{description}
\item[Geographic:] Geographic information includes the device's
longitude, latitude, altitude, velocity and heading, as well as
information about the precision of these values.  The precision is
expressed in either bits of resolution or an error radius. 
\motivation{Bits of resolution is more natural if the information is,
for example, provided via DHCP \citeinform{geoloc}.}

Not all of these elements need to be provided.

\item[Civil:] Civil location describes the device's whereabouts by
descriptors such as country, city, street and landmark.  Not all of
these information elements need to be provided.

\item[Timezone:] The timezone indication indicates the current offset
from GMT at the tuple's location.  \motivation{While the timezone can be
deduced from sufficiently accurate geographical or civil location
information, it is often sufficient for the watcher to know what time of
day it is at the contact's location.}

\item[Categorical:] The categorical location information describes, as
an enumeration, the type of location the device is currently at. 
Location categories can be either drawn from a list of common
designations or be free-text.  An initial list includes
``place-of-worship'', ``restaurant'', ``theater'', ``hospital'', ``home'', ``office'',
``outdoors'', ``vehicle'', ``ship'', ``plane'', ``train''.

\motivation{Categorical location information offers the watcher
additional hints at what kind of communication is likely to be
appropriate or can be used by a service agent to construct appropriate
policies.  While this information may be derivable via the civil or
geographical information, it appears to have fewer privacy issues and
offers a more functionally rich indication for communication.}

\item[Behavioral:] The behavorial location indication describes
properties of the locale associated with a tuple.  The list of
properties is extensible; it initially includes ``privacy'' and
``noise''.  ``Privacy'' indicates whether the mode of communication is
likely to remain private between the caller and callee.  A phone call in
a public place or a video call on a meeting room video screen are not
likely to offer privacy to the caller.  We distinguish the values
``private'', where only the intended recipient is likely to hear the
caller, ``semi-private'', where colleagues, friends and family members
may overhear the caller, and ``public'', where anybody could be party to
one or both sides of the conversation.

``Noise'' indicates the level of background noise to be expected,
expressed as ``quiet'', ``normal'', ``loud''.

\end{description}

Each tuple can have zero or more of these location elements.  In
addition, the tuple may contain additional elements restricting the
handling of location information \cite{geopriv}.  By default, the
information is not to be forwarded to anybody else or stored.

         <ep:location>
           <ep:location-category>office</>
           <ep:location-timezone>-6</>
           <ep:location-civil country="us" landmark="Rockefeller Center"></>
           <ep:privacy>semi-private</>
           <ep:noise>quiet</>
         </>

         <ep:location>
           <ep:category>office</>
           <ep:privacy>private</>
         </>

\subsection{Liveness}
\label{sec:liveness}

The \xmlelement{liveness} element describes whether the the person
contacting the device is likely to encounter a person or a machine.

\begin{description}
\item[live:] A ``live'' contact is answered by a human being.

\item[recorder:] A recorder simply records the communication for later
delivery to the contact.  Examples include answering machines, voicemail
systems, IM store-and-forward systems or IM-to-email gateways.

\item[robot:] A robot responds to queries, but does not record
communications.  Examples include interactive voice response (IVR)
systems that provide automated information, e.g., on flight arrival
times or stock quotes, or an IM or SMS autoanswer robot that answers
common queries based on keywords or natural-language processing.

\end{description}

It is possible for an RPIDS description to have multiple
\xmlelement{liveness} entries, for example, for a device where the
presentity does not know (or want to reveal) whether it will be answered
by a human or go to a recording device. 

\motivation{This element differs from the caller preference
``msg-server'' designation in that it does not merely describe a
capability, but rather a current property.}


\subsection{Priority}
\label{sec:priority}

A presentity can indicate, at the presentity or tuple level, that it
does not wish to be disturbed except under certain circumstances.  A
tuple inherits a priority declared at the \xmlelement{presentity} level,
but an \xmlelement{priority} within a tuple overrides the inherited
value.

\motivation{This inheritance saves space, but makes composing somewhat
more difficult. TBD: Worth the hassle?}

Similar to the \header{Priority} indicator in \citeinform{callerprefs},
the \xmlelement{priority} element indicates whether routine, urgent or
emergency calls are likely to be answered.  A value of ``emergency'' or
``urgent'' corresponds to the usual ``do-not-disturb'' indication found
in many systems.

\motivation{We intentionally did not add an explicit ``do-not-disturb''
indication to prevent communication.  The watcher cannot be trusted to
obey such indications in any event.  Thus, communication restrictions
have to be implemented by the presentity.  Presence indication is about
disclosing status, not controlling communications.  As noted in the
introduction, presentity-controlled entities can subscribe to this
information and in turn use this information to restrict communications
attempts.}

TBD: overlap with \citeinform{draft-lonnfors-simple-prescaps-ext}.

\subsection{Media}
\label{sec:media}

The \xmlelement{media} element enumerates the media types supported by
the tuple.  It extends the \xmlelement{tuple} element in PIDF and thus
describes all \xmlelement{contact} elements within the tuple.

The media types are drawn from the set of Internet media types.  For the
media type ``application'', a more precise designation can be added,
e.g., ``application/chess''.  The token ``application'' indicates
generic application sharing.

In addition, we define the pseudo-mediatype ``inperson'' to designate
face-to-face communication.

Alternatively, the presence capability designation in
\citeinform{draft-lonnfors-simple-prescaps-ext} may be used.

\motivation{The media description should really extend
\xmlelement{contact}, but the PIDF schema does not support this.}

\subsection{Privacy}
\label{sec:privacy}

The \xmlelement{privacy} element describes the expected amount of
privacy the communication can offer. We distinguish three values,
``alone'', ``group'' and ``crowd'', to indicate whether the contact is
alone, in a small group of people or a large crowd. The list can be
augmented by IANA registration (Section~\ref{sec:iana}).

\motivation{This provides a rough indication of privacy for audio
communications and may be useful for planning in-person visits, but is
probably less useful for other media.  With some effort, this value can
be derived automatically from video imagery.} 

  <xs:element name="privacy" type="xs:token"/>

