RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
Extracted elements (32)
A two-state model ('active'/'idle') was chosen for <user-input> because a finer-grained model would require repeated last-input updates during continuous activity, generating excessive presence traffic.
Many RPID elements (appointment, breakfast, travel, vacation, etc.) were chosen to align with iCalendar category fields so that presence information can be automatically derived from personal calendars without manual user intervention.
RPID tokens are intended for consumption by programs rather than directly by humans; programs are expected to translate tokens into language-appropriate text per watcher preferences. Free-text <note> and <other> elements carry human-readable content and SHOULD be labeled with xml:lang.
RPID was designed to maintain backward compatibility with PIDF so that PIDF-only watchers and gateways continue to function correctly, naturally without access to the richer information. All RPID elements are optional within PIDF documents.
Due to XML Schema limitations, the RPID schema allows each element to appear anywhere within PIDF or data-model elements; Table 1 in Section 3.1 defines the semantically valid placement constraints (which elements may appear under <person>, <tuple>, or <device>) that the schema cannot enforce alone.
Configuration MUST include the option to omit the 'last-input' attribute from <user-input>, allowing a presentity to indicate idle state without revealing the precise duration of inactivity.
Elements that do not carry from/until parameters MUST NOT appear more than once within a single <person>, <tuple>, or <device> element.
Groups of element registrations for a given enumeration (e.g., <privacy> extensions) SHOULD be bundled into a single namespace rather than assigning a new namespace to each new element, to avoid unnecessary namespace proliferation.
Implementations are RECOMMENDED to support the mood values proposed in Jabber Extension JEP-0107, which are a superset of Wireless Village mood values and the Affective Knowledge Representation values.
Publishers on mobile devices SHOULD NOT publish <time-offset> information unless they know the time offset reflects their current location; publishers SHOULD update the information whenever the UTC offset changes.
The <class> and <deviceID> elements MUST NOT be qualified with 'from' and 'until' attributes.
The service-class values 'postal', 'courier', 'freight', and 'in-person' MUST NOT be used unless the <contact> URI in the tuple is empty, since these classes represent physical delivery rather than electronic communication.
Watchers resolving the <status-icon> URI MUST validate whether the local copy of the icon is current when receiving a notification, using the standard cache control mechanism of the retrieval protocol.
The <activities> element describes what the person is currently doing, expressed as an enumeration of activity-describing child elements (e.g., <meeting/>, <travel/>, <vacation/>). A person may be engaged in multiple activities simultaneously, and the element may carry 'from' and 'until' temporal attributes.
The <class> element assigns a presentity-defined label grouping similar person, device, or service elements within a presence document. Each person, service, or device may carry only one class label; its content is not presented to watchers but is used for filtering or authorization.
The <deviceID> element within a <tuple> references the <device> element that provides the described service. One service may reference multiple devices; there is no significance to element order.
The <mood> element describes the mood of the presentity using child elements drawn from a defined enumeration (e.g., <happy/>, <sleepy/>). One child mood element is REQUIRED; an optional <note> child may provide a natural-language description.
The <place-is> element reports properties of the presentity's current physical environment using per-media-type sub-elements: <audio> (noisy/ok/quiet/unknown), <video> (toobright/ok/dark/unknown), and <text> (uncomfortable/inappropriate/ok/unknown). This helps watchers judge which communication modality is likely to succeed.
The <place-type> element describes the type of location the person is currently at, with values drawn from RFC 4589 (Location Types Registry). It may be qualified with 'from' and 'until' attributes and can be extended with IANA-registered values.
The <privacy> element indicates which communication modalities (audio, text, video) third parties in the vicinity of the presentity are unlikely to intercept. It explicitly does not describe electronic channel encryption properties.
The <relationship> element extends <tuple> to designate the relationship of an alternate contact to the presentity; values include assistant, associate, family, friend, self, supervisor, and unknown. The default is 'self'; if a non-self relationship is indicated, the <contact> URI refers to that related entity, not the presentity.
The <service-class> element extends <tuple> and designates the delivery modality of a service: electronic, postal, courier, freight, or in-person. Electronic is implied if the element is omitted.
The <sphere> element designates the presentity's current overall role (e.g., 'work', 'home', or a custom value). It is intended for use with authorization rules, allowing the presentity to control which groups of contacts can see their presence based on their current sphere.
The <status-icon> element contains a URI pointing to an image representing the presentity's current status. It may qualify with 'from' and 'until' attributes and may appear in both <person> and <tuple> elements.
The <time-offset> element encodes the presentity's UTC offset in minutes as an integer (positive = east, negative = west). An optional 'description' attribute holds a human-readable time zone label.
The <user-input> element records the usage state of a service, device, or person as either 'active' or 'idle', with optional 'last-input' (xs:dateTime) and 'idle-threshold' (seconds) attributes. When contained in a <person> element, it summarizes input activity across all devices and services.
This document registers the URN sub-namespace 'urn:ietf:params:xml:ns:pidf:rpid' in the IETF XML Registry (BCP 81, RFC 3688) for use as the XML namespace for RPID extension elements within application/pidf+xml documents.
This document registers the XML schema 'urn:ietf:params:xml:ns:pidf:status:rpid' in the IANA XML schema registry; the schema content is defined in Section 5 of the RFC.
RPID reveals substantially more sensitive information about a presentity than basic PIDF (activities, mood, location type, time zone, etc.). Systems MUST offer mechanisms for selective disclosure to particular watchers and for inspecting automatically generated presence data before publication.
The <status-icon> URI reference enables a content indirection attack: a malicious presentity could cause the watcher to retrieve harmful content from a third-party server or impose load on that server by embedding an adversarial URI.
RPID is encoded as an XML document within the existing 'application/pidf+xml' content type; no new content type is registered. RPID elements reside in namespace 'urn:ietf:params:xml:ns:pidf:rpid' and extend the <tuple>, <person>, and <device> elements defined in PIDF and the PIDF data model.
The <user-input> element content is the xs:string enumeration 'active' or 'idle'. It carries optional xs:positiveInteger attribute 'idle-threshold' (seconds) and optional xs:dateTime attribute 'last-input'. The <time-offset> element content is xs:integer (minutes from UTC).