Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)
Extracted elements (28)
A SIP URI scheme can represent voice, video, or messaging services, making it ambiguous for watchers processing presence information. This extension maps RFC 3840 UA capability feature tags into PIDF XML so watchers can make rational decisions about how to contact a presentity before initiating communication.
PUAs should add information under <supported> and <notsupported> only when it may affect watcher decision-making; listing all possible information is rarely needed. This keeps presence documents concise and avoids flooding watchers with irrelevant capability data.
This extension does not replace SIP media negotiation mechanisms such as SDP. Its purpose is to give watchers hints about a presentity's preferences, willingness, and capabilities before communication is initiated, not to negotiate session parameters.
Presence information published via this extension is not mandated to be consistent with actual service or device capabilities. Watchers should not expect full alignment between advertised capabilities and real capabilities; the extension provides hints, not guarantees.
When a capability value appears under both <supported> and <notsupported> with the same value (conflicting information), the watcher can safely assume the capability is supported, regardless of its presence under <notsupported>.
It is RECOMMENDED that Presence User Agents (PUAs) using this extension provide as complete presence information as they can. If publishing sensitive information, the PUA SHOULD obtain permission from the presentity.
The <devcaps> element SHOULD be located in the PIDF document as a child element of the urn:ietf:params:xml:ns:pidf:data-model namespace <device> element.
The <servcaps> element SHOULD be located in the PIDF document as a child element of the urn:ietf:params:xml:ns:pidf namespace <tuple> element.
When extension namespaces defined by this document are combined with a PIDF document, the combined document MUST follow the same general formatting rules specified in Section 4.1 of RFC 3863.
Boolean media-type capability elements <audio>, <application>, <data>, <control>, <video>, <text>, and <message> each indicate whether the service supports the corresponding streaming media type as defined in RFC 3840 (or RFC 4569 for message). A value of 'true' indicates support; 'false' indicates no support.
The <actor> element indicates the type of entity at the service URI: <principal> (direct communication with the person), <attendant> (intermediary), <msg-taker> (message-taking automaton or person), or <information> (information provider). Uses <supported> and <notsupported> containers.
The <automata> element is a boolean indicating whether the service represents an automaton (e.g., voicemail server, conference server, recording device) or a human, as defined in RFC 3840. Value 'true' means automaton; 'false' means human.
The <class> element indicates the setting (business or personal) in which a communications service is used. It contains <supported> and <notsupported> child elements, each of which can contain <business> and <personal> elements, plus extensions registered with IANA as sip.class feature tags.
The <description> element provides a free-text description of the service or device. It SHOULD carry an 'xml:lang' attribute; if absent, the default language is 'i-default' per RFC 2277. Multiple occurrences are allowed to convey descriptions in different languages.
The <devcaps> element is the root element for device capabilities and SHOULD appear as a child of the PIDF data-model <device> element. It can contain <mobility> and <description> child elements plus extensions. The namespace is urn:ietf:params:xml:ns:pidf:caps.
The <duplex> element lists whether the service can simultaneously send and receive media ('full'), alternate between sending and receiving ('half'), only receive ('receive-only'), or only send ('send-only'). It uses <supported> and <notsupported> child containers.
The <event-packages> element lists SIP event packages supported or not supported by a service, using <supported> and <notsupported> containers. Valid values are drawn from the IANA SIP event types namespace registry (e.g., conference, dialog, presence, refer, winfo).
The <extensions> element lists SIP option-tags (from IANA SIP parameters registry) understood by the service, corresponding to what would appear in a Supported header field. It uses <supported> and <notsupported> containers.
The <isfocus> element is a boolean indicating whether the service is a SIP conference server (focus). Value 'true' indicates a conference server; 'false' indicates no conferencing support.
The <languages> element indicates the human languages the service can display, using <supported> and <notsupported> containers with <l> string children. Values are language subtags registered in the IANA language subtag registry per RFC 4646.
The <methods> element indicates SIP methods that the service can receive (analogous to the SIP Allow header field). Methods are listed in <supported> and <notsupported> containers using values from the IANA SIP parameters registry methods table (e.g., INVITE, BYE, MESSAGE, SUBSCRIBE).
The <mobility> element indicates whether a device is <fixed> (stationary, associated with a fixed network point) or <mobile> (not associated with a fixed point). Note that cordless phones are classified as fixed, not mobile, per RFC 3840.
The <priority> element indicates call priority values the service is willing to handle, expressed via <lowerthan maxvalue>, <higherthan minvalue>, <equals value>, and <range minvalue maxvalue> child elements under <supported> and <notsupported> containers.
The <schemes> element provides the set of URI schemes the service supports, using <supported> and <notsupported> containers with <s> string child elements. Values are scheme names registered in the IANA URI scheme registry.
The <servcaps> element is the root element for service capabilities and SHOULD appear as a child of the PIDF <tuple> element in the urn:ietf:params:xml:ns:pidf namespace. It can contain child elements for audio, application, data, control, video, text, message, type, automata, class, duplex, description, event-packages, priority, methods, extensions, schemes, actor, isfocus, and languages, plus extension elements from other namespaces.
The <type> element indicates a MIME media content type supported by the service, as defined in RFC 2913. It is a string type that MUST be of the form 'type/subtype', where type and subtype are defined by the MIME specification (RFC 2045). Only lowercase letters SHOULD be used.
RFC 5196 registers the XML namespace URN 'urn:ietf:params:xml:ns:pidf:caps' and the XML schema URN 'urn:ietf:params:xml:schema:pidf:caps' in the IETF XML Registry (RFC 3688) for the PIDF service and device capability extension elements.
All security considerations from RFC 3859 (CPP) and RFC 3863 (PIDF) apply. Compared to baseline PIDF, this extension may reveal additional sensitive information about a user's service and device capabilities, so the PUA SHOULD always obtain permission from the presentity before publishing such information.