Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals
Extracted elements (17)
Absolute rather than relative times were chosen for <timed-status> because relative times would be too hard to keep properly updated when spacing notifications. This avoids drift and ambiguity when presence documents are cached or republished.
It is not possible to simply add time range attributes to the PIDF <status> element because PIDF parsers without this capability would ignore those attributes and be unable to distinguish current from future presence status information, motivating the separate <timed-status> child element approach.
Past presence information is included in scope because it may be the only known presence information and can give watchers an indication of current status (e.g., a meeting that ended an hour ago implies the presentity is likely in transit).
The <timed-status> element extends PIDF (RFC 3863) and is compatible with RPID (RFC 4480); it is placed as a child of <tuple> rather than <status> to ensure that legacy PIDF parsers do not silently treat timed status as current status.
More than one <timed-status> element MAY appear within a PIDF <tuple> element.
Originators of presence information MUST generate time values in <timed-status> elements that are fully in the past or future relative to local wallclock time and the optional PIDF <timestamp> element.
Receivers MUST be able to render overlapping <timed-status> indications, since overlapping appointments are common in calendars even though sources should avoid overlapping time intervals.
The time range of a <timed-status> element MUST NOT encompass the present time (i.e., the PIDF <timestamp> value), as this would create an unnecessary and confusing alternate mechanism for current presence. For tuples without an 'until' attribute, the 'from' attribute MUST refer to the future.
The <timed-status> element MUST be qualified with the 'from' attribute (xs:dateTime) and MAY be qualified with an 'until' attribute to bound the valid time interval.
The <timed-status> element MUST NOT appear as a child of a PIDF <status> element or another <timed-status> element.
During composition, a presence agent (PA) encountering a stored <timed-status> element that covers the present time MAY either discard that element or convert it to a regular <status> element if it considers that information more credible.
If the 'until' attribute is missing from <timed-status>, the information is assumed valid until the tuple is explicitly overridden or expires as defined by the publication mechanism used.
The <timed-status> element is a child of the PIDF <tuple> element and extends presence information to cover time intervals fully in the past or future. It may contain <basic> and <note> elements, as well as other PIDF <status> extensions with limited validity periods.
This document registers a new URN sub-namespace 'urn:ietf:params:xml:ns:pidf:timed-status' in the IETF XML Registry (per RFC 3688) for XML elements defined by RFC 4481.
This document registers the XML schema for 'urn:ietf:params:xml:ns:pidf:timed-status' in the IETF XML Registry, with the schema defined in Section 5.
The security issues for the timed-status PIDF extension are similar to those for RPID (RFC 4480). No additional security considerations specific to timed-status are identified beyond those applicable to RPID.
The <timed-status> XML element carries a required 'from' attribute (xs:dateTime) and an optional 'until' attribute (xs:dateTime), plus optional child elements <basic> (pidf:basic type), <note> (pidf:note type), and extensible content via xs:any with lax processing.