Request for Comments: 3863 S. Fujimoto
Category: Standards Track Fujitsu
G. Klyne
Nine by Nine
A. Bateman
VisionTech
W. Carr
Intel
J. Peterson
NeuStar
August 2004
Presence Information Data Format (PIDF)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo specifies the Common Profile for Presence (CPP) Presence
Information Data Format (PIDF) as a common presence data format for
CPP-compliant Presence protocols, and also defines a new media type
"application/pidf+xml" to represent the XML MIME entity for PIDF.
Table of Content
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Conventions. . . . . . . . . . . . . . . 3
2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Minimal Model. . . . . . . . . . . . . . . . . . . . . . 3
2.2. Added Features . . . . . . . . . . . . . . . . . . . . . 4
2.3. XML Encoding Decision. . . . . . . . . . . . . . . . . . 5
3. Overview of Presence Information Data Format . . . . . . . . . 5
3.1. The ’application/pidf+xml’ Content Type. . . . . . . . . 5
3.2. Presence Information Contents. . . . . . . . . . . . . . 5
4. XML-encoded Presence Data Format . . . . . . . . . . . . . . . 6
4.1. XML Format Definitions . . . . . . . . . . . . . . . . . 6
4.1.1. The <presence> element. . . . . . . . . . . . . . 6
4.1.2. The <tuple> element . . . . . . . . . . . . . . . 7
4.1.3. The <status> element. . . . . . . . . . . . . . . 8
4.1.4. The <basic> element . . . . . . . . . . . . . . . 8
4.1.5. The <contact> element . . . . . . . . . . . . . . 8
4.1.6. The <note> element. . . . . . . . . . . . . . . . 9
4.1.7. The <timestamp> element . . . . . . . . . . . . . 9
4.2. Presence Information Extensibility . . . . . . . . . . . 10
4.2.1. XML Namespaces Background . . . . . . . . . . . . 10
4.2.2. XML Namespaces In Presence Information. . . . . . 11
4.2.3. Handling Of Unrecognized Element Names. . . . . . 12
4.2.4. Status Value Extensibility. . . . . . . . . . . . 12
4.2.5. Standardizing Status Extensions . . . . . . . . . 13
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Default Namespace with Status Extensions. . . . . 14
4.3.2. Presence with Other Extension Elements. . . . . . 15
4.3.3. Example Mandatory To Understand Elements. . . . . 16
4.4. XML Schema Definitions . . . . . . . . . . . . . . . . . 16
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
5.1. Content-type registration for ’application/pidf+xml’ . . 18
5.2. URN sub-namespace registration for
’urn:ietf:params:xml:ns:pidf’. . . . . . . . . . . . . . 19
5.3. URN sub-namespace registration for
’urn:ietf:params:xml:ns:pidf:status’ . . . . . . . . . . 20
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
7. Internationalization Considerations. . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Document Type Definitions. . . . . . . . . . . . . . . 25
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction
The Common Profiles for Instant Messaging (CPIM) [CPIM] and Presence
(CPP) [CPP] specifications define a set of operations and parameters
to achieve interoperability between different Instant Messaging and
Presence protocols which meet RFC 2779 [RFC2779].
This memo further defines the Presence Information Data Format (PIDF)
as a common presence data format for CPP-compliant presence
protocols, allowing presence information to be transferred across
CPP-compliant protocol boundaries without modification, with
attendant benefits for security and performance.
The format specified in this memo defines the base presence format
and extensibility required by RFC 2779. It defines a minimal set of
presence status values defined by the IMPP Model document [RFC2778].
However, a presence application is able to define its own status
values using the extensibility framework provided by this memo.
Defining such extended status values is beyond the scope of this
memo.
Note also that this memo defines only the format for a presence data
payload and the extensibility framework for it. How the presence
data is transferred within a specific protocol frame would be defined
separately in a protocol specification.
1.1. Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model
document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN,
PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the
memo are used in the same meaning as defined therein.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14, RFC 2119 [RFC2119].
2. Design Decisions
We have adopted the IMPP Model and Requirements documents [RFC2778,
RFC2779] as the starting point of our discussion. The two RFCs
contain a number of statements about presence information, which can
be regarded as a basic set of constraints for the format design.
Also, we took the minimalist approach to the design based on them.
Starting from the minimal model, only the features that are necessary
to solve particular problems have been included.
2.1. Minimal Model
This specification is based on the minimal model extracted from the
IMPP Model and Requirements documents. The model consists of the
following items. Each of them is accompanied with the corresponding
RFCs and their section numbers as its grounds, e.g.,
(RFC2778:Sec.2.4) refers to Section 2.4 of RFC 2778.
(a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES,
where a PRESENCE TUPLE consists of a STATUS, an optional
COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. Note
that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is
understood in this document to refer only to a URI
(RFC2778:Sec.3).
(b) STATUS has at least the mutually-exclusive values OPEN and
CLOSED, which have meaning for the acceptance of INSTANT
MESSAGES, and may have meaning for other COMMUNICATION MEANS.
There may be other values of STATUS that do not imply anything
about INSTANT MESSAGE acceptance. These other values of STATUS
may be combined with OPEN and CLOSED or they may be mutually-
exclusive with those values (RFC2778:Sec.3, RFC2779:Sec.4.4.1-
4.4.3).
(c) STATUS may consist of single or multiple values.(RFC2778:Sec.2.4)
(d) There must be a means of extending the common presence format to
represent additional information not included in the common
format. The extension and registration mechanisms must be
defined for presence information schema, including new STATUS
conditions and new forms for OTHER PRESENCE MARKUP
(RFC2779:Sec.3.1.4-3.1.5).
(e) The common presence format must include a means to uniquely
identify the PRESENTITY whose PRESENCE INFORMATION is reported
(RFC2779:Sec.3.1.2).
(f) The common presence format must allow the PRESENTITY to secure
presence information sent to a WATCHER. The format must allow
integrity, confidentiality and authentication properties to be
applied to presence information (RFC2779:Sec5.2.1, 5.2.4, 5.3.1,
5.3.3).
2.2. Added Features
In addition to the minimal model described above, the format
specified in this specification has the following features.
(a) Relative priorities of contact addresses are specifiable in order
to allow the source of PRESENCE INFORMATION to tell the receiver
(WATCHER USER AGENTS) its preference over multiple contact
means.
(b) The presence format is able to contain the timestamp of the
creation of the PRESENCE INFORMATION. The timestamp in the
presence document lets the receiver know the time of the
creation of the data even if the message containing it is
delayed. It can also be used to detect a replay attack,
independent of the underlying signature mechanism. Note that
this mechanism does not assume any global time synchronization
system for watchers and presentities (see Appendix A of RFC2779,
8.1.4 A7), but rather assumes that the minimum length of time
that might pass before presence information is considered stale
is long enough that minor variations among system clocks will
not lead to misjudgments of the freshness of presence
information.
2.3. XML Encoding Decision
The Presence Information Data Format encodes presence information in
XML (eXtensible Markup Language [XML]). Regarding the features of
PRESENCE INFORMATION discussed above, such that it has a hierarchical
structure and it should be fully extensible, XML is considered as the
most desirable framework over other candidates such as vCard [vCard].
3. Overview of Presence Information Data Format
This section describes an overview of the presence data format
defined in this memo.
3.1. The ’application/pidf+xml’ Content Type
This memo defines a new content type "application/pidf+xml" for an
XML MIME entity that contains presence information. This
specification follows the recommendations and conventions described
in [RFC3023], including the naming convention of the type (’+xml’
suffix) and the usage of the ’charset’ parameter.
Although it is defined as optional, use of the ’charset’ parameter is
RECOMMENDED. If the ’charset’ parameter is not specified, conforming
XML processors MUST follow the requirements in section 4.3.3 of
[XML].
3.2. Presence Information Contents
This subsection outlines the information in an "application/pidf+xml"
document. A full definition of the PIDF content is in Section 4.
o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY.
o List of PRESENCE TUPLES
- Identifier: token to identify this tuple within the presence
information.
- STATUS: OPEN/CLOSED and/or extension status values.
- COMMUNICATION ADDRESS: COMMUNICATION MEANS and CONTACT
ADDRESS of this tuple. (optional)
- Relative priority: numerical value specifying the priority
of this COMMUNICATION ADDRESS. (optional)
- Timestamp: timestamp of the change of this tuple.(optional)
- Human readable comment: free text memo about this tuple
(optional)
o PRESENTITY human readable comment: free text memo about the
PRESENTITY (optional).
4. XML-encoded Presence Data Format
This section defines an XML-encoded presence information data format
(PIDF) for use with CPP compliant systems. A presence payload in
this format is expected to be produced by the PRESENTITY (the source
of the PRESENCE INFORMATION) and transported to the WATCHERS by the
presence servers or gateways without any interpretation or
modification.
4.1. XML Format Definitions
A PIDF object is a well formed XML document.
It MUST have the XML declaration and it SHOULD contain an encoding
declaration in the XML declaration, e.g., "<?xml version=’1.0’
encoding=’UTF-8’?>". If the charset parameter of the MIME content
type declaration is present and it is different from the encoding
declaration, the charset parameter takes precedence.
Every application conformant to this specification MUST accept the
UTF-8 character encoding to ensure the minimal interoperability.
4.1.1. The <presence> element
PIDF elements are associated with the XML namespace name
’urn:ietf:params:xml:ns:pidf’, declared using an xmlns attribute, per
[XML-NS]. The namespace may be a default namespace, or may be
associated with some namespace prefix (see section 4.2.2 for
examples).
The root of an "application/pidf+xml" object is a <presence> element
associated with the presence information namespace. This contains
any number (including 0) of <tuple> elements, followed by any number
(including 0) of <note> elements, followed by any number of OPTIONAL
extension elements from other namespaces.
The <presence> element MUST have an ’entity’ attribute. The value of
the ’entity’ attribute is the ’pres’ URL of the PRESENTITY publishing
this presence document.
The <presence> element MUST contain a namespace declaration (’xmlns’)
to indicate the namespace on which the presence document is based.
The presence document compliant to this specification MUST have the
namespace ’urn:ietf:params:xml:ns:pidf:’.
It MAY contain other namespace declarations for the extensions used
in the presence XML document.
4.1.2. The <tuple> element
The <tuple> element carries a PRESENCE TUPLE, consisting of a
mandatory <status> element, followed by any number of OPTIONAL
extension elements (possibly from other namespaces), followed by an
OPTIONAL <contact> element, followed by any number of OPTIONAL <note>
elements, followed by an OPTIONAL <timestamp> element.
Tuples provide a way of segmenting presence information. Protocols
or applications may choose to segment the presence information
associated with a presentity for any number of reasons - for example,
because components of the full presence information for a presentity
have come from distinct devices or different applications on the same
device, or have been generated at different times. Tuples should be
preferred over other manners of segmenting presence information such
as creating multiple PIDF instances.
The <tuple> element MUST contain an ’id’ attribute which is used to
distinguish this tuple from other tuples in the same PRESENTITY. The
value of an ’id’ attribute MUST be unique within ’id’ attribute
values of other tuples for the same PRESENTITY. An ’id’ value is
used by applications processing the presence document to identify the
corresponding tuple in the previously acquired PRESENCE INFORMATION
of the same PRESENTITY. The value of the ’id’ attribute is an
arbitrary string, and has no significance beyond providing a means to
distinguish <tuple> values, as noted above.
The <contact> element is OPTIONAL because a PRESENTITY might need to
hide its COMMUNICATION ADDRESS or there might be tuples not related
to any COMMUNICATION MEANS. Tuples that contain a <basic> status
element SHOULD contain a <contact> address. Tuples MAY contain
conflicting presence status - one <tuple> might provide a <basic>
<status> of OPEN, and another <tuple> in the same PIDF could contain
a <basic> <status> of CLOSED, even if they both contain the same
<contact> address.
The manner in which segmented presence information is understood by
the WATCHER USER AGENT is highly dependent on the capabilities of the
WATCHER USER AGENT and the presence application in question. In the
absence of any application-specific or protocol-specific
understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey
the following guidelines. WATCHER USER AGENTS should note which
tuples in the PIDF have changed their state since the last
notification by correlating the ’id’ of each <tuple> with those
received in previous notifications and comparing both <status> values
and <timestamp> elements in the tuples, if any are present.
4.1.3. The <status> element
The <status> element contains one OPTIONAL <basic> element, followed
by any number of OPTIONAL extension elements (possibly from other
namespaces), under the restriction that at least one child element
appears in the <status> element. These children elements of <status>
contain status values of this tuple. By allowing multiple status
values in a single <tuple> element, different types of status values,
e.g., reachability and location, can be represented by a <tuple>.
See Section 4.3 for an example with multiple status values.
This memo only defines the <basic> status value element. Other
status values may be included using the standard extensibility
framework (see Section 4.2.4). Applications encountering
unrecognized elements within <status> may ignore them, unless they
carry a mustUnderstand="true" or mustUnderstand="1" attribute (see
section 4.2.3).
Note that, while the <status> element MUST have at least one status
value element, this status value might not be the <basic> element.
4.1.4. The <basic> element
The <basic> element contains one of the following strings: "open" or
"closed".
The values "open" and "closed" indicate availability to receive
INSTANT MESSAGES if the <tuple> is for an instant messaging address.
They also indicate general availability for other communication
means, but this memo does not specify these in detail.
open: In the context of INSTANT MESSAGES, this value means that the
associated <contact> element, if any, corresponds to an INSTANT
INBOX that is ready to accept an INSTANT MESSAGE.
closed: In the context of INSTANT MESSAGES, this value means that
the associated <contact> element, if any, corresponds to an
INSTANT INBOX that is unable to accept an INSTANT MESSAGE.
4.1.5. The <contact> element
The <contact> element contains a URL of the contact address. It
optionally has a ’priority’ attribute, whose value means a relative
priority of this contact address over the others. The value of the
attribute MUST be a decimal number between 0 and 1 inclusive with at
most 3 digits after the decimal point. Higher values indicate higher
priority. Examples of priority values are 0, 0.021, 0.5, 1.00. If
the ’priority’ attribute is omitted, applications MUST assign the
contact address the lowest priority. If the ’priority’ value is out
of the range, applications just SHOULD ignore the value and process
it as if the attribute was not present.
Applications SHOULD handle contacts with a higher priority as they
have precedence over those with lower priorities. How they are
actually treated is beyond this specification. Also, how to handle
contacts with the same priority is up to implementations.
4.1.6. The <note> element
The <note> element contains a string value, which is usually used for
a human readable comment. A <note> element MAY appear as a child
element of <presence> or as a child element of the <tuple> element.
In the former case the comment is about the PRESENTITY and in the
latter case the comment is regarding the particular tuple.
Note that, wherever it appears, a <note> element SHOULD NOT be used,
and interpreted, as a non-interoperable substitute for status of its
parent element.
The <note> element SHOULD have a special attribute ’xml:lang’ to
specify the language used in the contents of this element as defined
in Section 2.12 of [XML]. The value of this attribute is the
language identifier as defined by [RFC3066]. It MAY be omitted when
the language used is implied by the larger context such as the
encoding information of the contents, such as an xml:lang attribute
on an enclosing XML element, or a Content-language header [RFC3282]
on an enclosing MIME wrapper.
4.1.7. The <timestamp> element
The <timestamp> element contains a string indicating the date and
time of the status change of this tuple. The value of this element
MUST follow the IMPP datetime format [RFC3339]. Timestamps that
contain ’T’ or ’Z’ MUST use the capitalized forms.
As a security measure, the <timestamp> element SHOULD be included in
all tuples unless the exact time of the status change cannot be
determined. For security guidelines for watchers receiving presence
information with timestamps, see the Security Considerations.
A PRESENTITY MUST NOT generate successive <presence> elements
containing the same timestamp.
4.2. Presence Information Extensibility
The presence information extensibility framework is based on XML
namespaces [XML-NS].
RFC 2779 requires that PIDF have a means of extending <status> values
beyond <basic>. These extensions MUST NOT modify how <basic> is to
be understood, nor change the structure or semantics of PIDF bodies