rfc-4482

CIPID: Contact Information for the Presence Information Data Format

H. Schulzrinne
date2006-07 streamIETF arearai wgsimple statusPROPOSED STANDARD pages11 canonicalhttps://www.rfc-editor.org/rfc/rfc4482 doi10.17487/RFC4482
The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. [STANDARDS-TRACK]

Extracted elements (25)

design-rationale §7

CIPID delivers only URIs (except for <display-name>) so that language and character set negotiation can occur within the URL-designated protocol rather than within the PIDF document itself.

design-rationale §1

CIPID elements describe the more static aspects of a presentity's presence information (e.g., homepage, icon, card), while RPID focuses on elements that change throughout the day; this separation allows CIPID information to be statically configured through a GUI.

interoperability-note §1

CIPID can be used together with RPID (RFC 4480), future-status (RFC 4481), and other PIDF extensions in the same PIDF document, all extending the <person> or <tuple> elements in the presence data model (RFC 4479).

interoperability-note §7

The XML 'xml:lang' attribute identifies language and script for <display-name>; if omitted, the default value is 'i-default' per BCP 18 (RFC 2277).

normative-requirement §3 MUST NOT

Each CIPID element may only appear at most once, unless otherwise noted (display-name allows multiple occurrences for different xml:lang values).

normative-requirement §8 MUST NOT

If identity verification of a referenced server's certificate fails (e.g., for https URIs per RFC 2818 section 3.1), the referenced content SHOULD NOT be retrieved and MUST NOT be used.

tls, security

normative-requirement §3.4 SHOULD

Presentities SHOULD provide icon images of sizes and aspect ratios that are appropriate for rendering as an icon.

normative-requirement §3.4 REQUIRED

Support for JPEG, PNG, and GIF formats for the <icon> element is REQUIRED of implementations.

normative-requirement §3.5 REQUIRED

Support for PNG and GIF image formats for the <map> element is REQUIRED.

normative-requirement §3.6 RECOMMENDED

Support for sounds coded as MPEG-2 Layer 3 (MP3) for the <sound> element is RECOMMENDED.

normative-requirement §1 MUST NOT

The <tuple> element is only extended with CIPID elements if the information describes a service referring to another person that is marked by an RPID <relationship> element with a value other than 'self'.

normative-requirement §7 RECOMMENDED

Use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists.

protocol-element §3.1

The <card> element contains a URI pointing to a business card, such as in LDAP Data Interchange Format (LDIF) or vCard format, extending the <person> or <tuple> element in PIDF.

email

protocol-element §3.2

The <display-name> element contains the name that the presentity suggests should be shown by the watcher user interface. Multiple occurrences are allowed only if they carry different 'xml:lang' attributes to support multiple languages.

protocol-element §3.3

The <homepage> element provides a URI pointing to general information about the tuple or person, typically a web home page.

http

protocol-element §3.4

The <icon> element provides a URI pointing to an image representing the tuple or person for use in graphical user interfaces. Support for JPEG, PNG, and GIF formats is REQUIRED.

protocol-element §3.5

The <map> element provides a URI pointing to a map related to the tuple or person, which may be an image, an HTML client-side image map, or a GIS document (e.g., GML). Support for PNG and GIF image formats is REQUIRED.

protocol-element §3.6

The <sound> element provides a URI pointing to a sound object (e.g., MIDI or MP3) related to the tuple or person. Support for MPEG-2 Layer 3 (MP3) is RECOMMENDED; it may also be used to indicate name pronunciation.

registry §6.1

This document registers the URN sub-namespace 'urn:ietf:params:xml:ns:pidf:cipid' for XML elements defining CIPID contact information presence extensions for PIDF.

registry

registry §6.2

This document registers the XML schema for 'urn:ietf:params:xml:ns:pidf:cipid' per the IETF XML Registry (BCP 81, RFC 3688).

registry

security-consideration §8

Icons and other URIs in CIPID could function as a covert channel to convey messages to the watcher outside normal content monitoring; entities concerned about this may wish to prohibit URLs pointing to resources outside their domain.

security

security-consideration §8

Implementors must verify the identity in the referenced server's certificate against the URI (e.g., for https URIs, the domain must match the subjectAltName per RFC 2818 section 3.1); failure to verify MUST prevent use of the referenced content.

security, tls, pkix

security-consideration §8

Watchers need to restrict which content types they render when pointed to by <icon>, <homepage>, <map>, <sound>, and <card> elements, to prevent rendering malicious content.

security

security-consideration §8

When a watcher accesses CIPID URIs, the presentity can deduce the watcher is currently active; a presence application may cache these objects to mitigate this privacy exposure, at the cost of potentially stale data.

security, privacy

wire-format §5

All CIPID elements except <display-name> have type xs:anyURI; <display-name> has type xs:string. The schema namespace is 'urn:ietf:params:xml:ns:pidf:cipid' with elementFormDefault='qualified'.