Presence Information Data Format (PIDF)
Extracted elements (27)
The mustUnderstand attribute is restricted to optional elements nested inside <status> only, ensuring that processing failures of an extension do not affect processing of the basic PIDF information and that minimal implementations remain correct.
The timestamp feature was added not only for freshness tracking but also as a replay-attack detection mechanism independent of any underlying signature mechanism, without requiring global time synchronization between watchers and presentities.
Tuples are preferred over multiple PIDF instances for segmenting presence information (e.g., from distinct devices or applications) because they keep all presence data for a presentity in a single document, aiding correlation via the 'id' attribute across successive notifications.
XML was chosen as the encoding for PIDF over alternatives such as vCard because presence information has a hierarchical structure and needs to be fully extensible; XML was considered the most desirable framework for these requirements.
Status extensions that introduce IM-style values (e.g., 'away', 'busy') MUST also include a <basic> status value to maintain interoperability with user agents that do not recognize the extension namespace.
A namespace URI used in presence information MUST be a full absolute-URI per RFC 2396; relative URIs and URI-references containing fragment identifiers MUST NOT be used.
A PIDF document MUST have the XML declaration and SHOULD contain an encoding declaration. Every conformant application MUST accept UTF-8 character encoding to ensure minimal interoperability.
A processor of presence information MUST ignore any XML element with an unrecognized name, including all its content. The mustUnderstand attribute MUST be used only within optional elements nested in a <status> element.
Extensions to PIDF MUST NOT modify how <basic> is to be understood, nor change the structure or semantics of PIDF bodies themselves; they merely allow protocols and applications to define richer presence data.
New status extension values under the namespace 'urn:ietf:params:xml:ns:pidf:status' MUST be defined by a standards-track RFC.
The <presence> element MUST have an 'entity' attribute containing the 'pres' URL of the presentity, and MUST contain a namespace declaration for 'urn:ietf:params:xml:ns:pidf'.
The <timestamp> element SHOULD be included in all tuples unless the exact time of the status change cannot be determined, as a security measure against replay attacks.
The <tuple> element MUST contain an 'id' attribute whose value MUST be unique within the 'id' attribute values of other tuples for the same presentity.
The value of the <contact> element's 'priority' attribute MUST be a decimal number between 0 and 1 inclusive with at most 3 digits after the decimal point. If the priority value is out of range, applications SHOULD ignore it and process as if the attribute were absent.
Tuples that contain a <basic> status element SHOULD contain a <contact> address. If the 'priority' attribute is omitted on <contact>, applications MUST assign the contact address the lowest priority.
The <basic> element contains one of the strings 'open' or 'closed', indicating whether the associated contact is ready to accept instant messages or other communications. 'open' means the instant inbox is ready; 'closed' means it is unable to accept.
The <contact> element contains a URL of the contact address and optionally carries a 'priority' attribute, a decimal number between 0 and 1 inclusive with at most 3 digits after the decimal point, where higher values indicate higher priority.
The <note> element contains a human-readable string comment and may appear as a child of <presence> (describing the presentity) or of <tuple> (describing that tuple). It SHOULD carry an 'xml:lang' attribute per RFC 3066 and SHOULD NOT be used as a non-interoperable substitute for status.
The <presence> element is the root of a PIDF document, associated with namespace 'urn:ietf:params:xml:ns:pidf'. It contains zero or more <tuple> elements, followed by zero or more <note> elements, followed by optional extension elements, and MUST have an 'entity' attribute carrying the 'pres' URL of the presentity.
The <status> element contains one optional <basic> element followed by optional extension elements; at least one child element MUST appear. Extensions within <status> may carry a mustUnderstand='true' or '1' attribute to signal mandatory processing.
The <timestamp> element contains a date-time string following the IMPP datetime format (RFC 3339). Timestamps containing 'T' or 'Z' MUST use capitalized forms, and a presentity MUST NOT generate successive <presence> elements with the same timestamp.
The <tuple> element carries a PRESENCE TUPLE consisting of a mandatory <status> element, optional extension elements, an optional <contact> element, optional <note> elements, and an optional <timestamp> element. It MUST have an 'id' attribute whose value is unique within all tuples for the same presentity.
RFC 3863 registers the MIME media type 'application/pidf+xml' with IANA for representing XML-encoded presence information. The type is designated for LIMITED USE and follows RFC 3023 conventions.
RFC 3863 registers the URN sub-namespace 'urn:ietf:params:xml:ns:pidf:status' with IANA as an umbrella namespace for standardized extensions to the <status> PIDF element; each extension RFC must register a name under this namespace.
Presence is privacy-sensitive; the presence protocol MUST have capabilities to protect PIDF against eavesdropping, corruption, tampering, and replay attacks, operable end-to-end between presentities and watchers even across CPP gateways. S/MIME (RFC 3851) at the MIME level is recommended.
Timestamps in PIDF provide rudimentary replay-attack protection. A watcher receiving presence information whose newest timestamp is older than the newest timestamp in the last received presence information SHOULD ignore it as outdated.
PIDF is encoded as a well-formed XML document using the MIME content type 'application/pidf+xml'. The charset parameter (optional but RECOMMENDED) indicates character encoding; if absent, conforming XML processors MUST follow XML section 4.3.3 encoding detection rules.