A Data Model for Presence
Extracted elements (27)
Attributes are affiliated with the component they describe, not the component that reported them. For example, if a cell phone reports that a user is in a meeting, that 'in-a-meeting' attribute belongs in the Person component because it describes the human user, not the device.
Reach information uniquely identifies a service within a presence document: two services in a document cannot share identical reach information, because a watcher would then have no way to choose between them. Reach information is a 'weak contract'—it indicates the presentity's intent but does not guarantee connection to the described service.
Services are not centrally enumerated; anything exhibiting the required properties (characteristics, reach information, status, relative information) qualifies as a service. This avoids definitional problems when a service spans multiple software agents, lacks a distinct network address, or is defined by complex dispatch logic.
The absence of a presence attribute from a document makes no definitive statement about its value—it may be withheld due to privacy filtering or unsupported by the presentity's software. This follows the RFC 3840 precedent for capability declarations: omission means 'unknown', not 'not present'.
The device component enables service correlation: by linking services to a shared device ID, a presence server can infer the availability of one service from the state of another service or the device itself (e.g., inferring device non-idleness from an active VoIP call reported by a co-located IM application).
The presence data model introduces three distinct components—Person, Service, and Device—to fill gaps in RFC 2778 and RFC 3863, which modeled presence only as tuples without clearly distinguishing the human user, the communications service, and the physical device. Each component addresses a different aspect of a user's ability and willingness to communicate.
A PIDF client that does not implement this specification will silently ignore the <device> and <person> elements because they reside in a different namespace. The <tuple>-based service encoding is intentionally aligned with RFC 2778 and RFC 3863 semantics, ensuring backward compatibility with older implementations.
All future presence attributes MUST be defined as children of the <tuple> element, not the <status> element. Pre-existing attributes (such as <basic>) that were originally placed under <status> remain there for backward compatibility.
Extension schemas that themselves require extensibility MUST define points of extension in the schema, and SHOULD use the <any namespace="##other"> construct for doing so.
For devices with a MAC address, version 1 UUIDs are RECOMMENDED as the device ID, as they produce a time-based identifier that incorporates the MAC address. For devices without a MAC address, a version 4 (random) UUID is RECOMMENDED.
Implementations SHOULD include <geopriv> location objects as part of the person and/or device components of a presence document (not under <tuple>), but SHOULD also be prepared to receive presence documents with <geopriv> as a child of <tuple>, as defined in RFC 4119 prior to this specification.
It is RECOMMENDED that a presence document contain as many presence attributes as the presentity is willing and able to provide to a watcher, since absence conveys no information and documents achieve maximum value when well-populated.
Presence documents created according to this model MUST be valid per the defined XML schemas, with one exception: a compositor MAY produce a document it cannot fully validate if it validates under lax processing rules. Implementations SHOULD be prepared to receive and extract information from documents that are not fully valid.
When a new presence extension defines elements intended as children of an extensibility point declared as <any namespace="##other">, the extension MUST use a different namespace than that of its parent elements to avoid collisions.
Ambiguity—when multiple sources report conflicting state for a person, service, or device—is modeled by permitting multiple occurrences of each component, each with a unique occurrence identifier scoped within the presentity's document. The ambiguity is left for the consuming watcher or compositor to resolve.
Service status includes at minimum a basic open/closed indicator: 'closed' means communications will likely fail or not reach the intended party; 'open' means communications will likely succeed and reach the desired target. Additional status elements may convey finer-grained availability details.
The Device component models the physical operating environment in which services execute. Devices are identified by a globally and temporally unique device ID (a URN). Device characteristics include physical properties (display size, CPU speed); device status includes dynamic properties (power state, battery level, geographic location).
The Person component models the human user's static characteristics (e.g., aliases) and dynamic status (e.g., 'in a meeting', 'on the phone'). There is conceptually one person per presentity, but multiple occurrences are permitted to represent ambiguity from conflicting data sources.
The Presentity URI uniquely identifies a presentity and is ideally set to the identifier used to request the document (e.g., the Request-URI of a SIP SUBSCRIBE). It is independent of any specific service or device and represents a 'one-number' communications handle from which all service URIs can be discovered.
The Service component models a point of reachability for communications and consists of four sub-parts: characteristics (static descriptors of the service's nature and capabilities), reach information (how to contact the service, including a service URI), relative information (priority), and status (dynamic availability such as open/closed).
This document registers the URN sub-namespace urn:ietf:params:xml:ns:pidf:data-model as the XML namespace for the presence data model elements (<person>, <device>, <deviceID>).
This document registers the XML schema urn:ietf:params:xml:schema:pidf:data-model, which defines the <deviceID>, <device>, and <person> elements used to encode the three-component presence data model in PIDF documents.
Integrity of presence information is critical; modification by an attacker can lead to diverted communications. Transport protocols such as SIP for presence are relied upon to provide the necessary integrity functions for presence data.
Presence information is highly sensitive and requires privacy filtering—authorization-based removal of attributes a watcher is not permitted to see—before divulging it. RFC 3856 mandates such authorization processing, and the data model is designed so that individual attributes can be selectively withheld.
Services are encoded as <tuple> elements within <presence>; the service URI is carried in the <contact> child element. The 'id' attribute of <tuple> carries the service occurrence identifier. New attributes appear as direct children of <tuple>; pre-existing status attributes (e.g., <basic>) remain under <status>.
The <device> element (namespace urn:ietf:params:xml:ns:pidf:data-model) is a child of <presence> with a required 'id' attribute. It contains zero or more extensible status/characteristic elements, a required <deviceID> element holding the device URN, optional <note> elements, and an optional <timestamp>.
The <person> element (namespace urn:ietf:params:xml:ns:pidf:data-model) is a child of <presence> with a required 'id' attribute (xs:ID) carrying the occurrence identifier. It contains zero or more extensible status/characteristic elements, optional <note> elements (each optionally bearing xml:lang), and an optional <timestamp>.