themselves. These extensions merely allow protocols and applications
to define richer presence data.
4.2.1. XML Namespaces Background
All elements and some attributes are associated with a "namespace",
which is in turn associated with a globally unique URI. Any
developer can introduce their own element names, avoiding conflict by
choosing an appropriate namespace URI.
Within the presence data, element or attribute names are associated
with a particular namespace by a namespace prefix, which is a leading
part of the name, followed by a colon (":"); e.g.,
<prefix:element-name ...> ... </prefix:element-name>
Where, ’prefix’ is the header name prefix, ’element-name’ is a name
which is scoped by the namespace associated with ’prefix’. Note that
the choice of ’prefix’ is quite arbitrary; it is the corresponding
URI that defines the naming scope. Two different prefixes associated
with the same namespace URI refer to the same namespace.
A default namespace can be declared for XML elements without a
namespace prefix. The default namespace does NOT apply to attribute
names, but interpretation of an unprefixed attribute can be
determined by the containing element.
A namespace is identified by a URI. In this usage, the URI is used
simply as a globally unique identifier, and there is no requirement
that it can be used to retrieve a web resource, or for any other
purpose. Any legal globally unique URI MAY be used to identify a
namespace. (By "globally unique", we mean constructed according to
some set of rules so that it is reasonable to expect that nobody else
will use the same URI for a different purpose.)
For further details, see the XML namespace specification [XML-NS].
4.2.2. XML Namespaces In Presence Information
A URI used as a namespace identifier in PRESENCE INFORMATION data
MUST be a full absolute-URI, per RFC 2396 [URI]. (Relative URIs and
URI-references containing fragment identifiers MUST NOT be used for
this purpose.)
The namespace URI for elements defined by this specification is a URN
[URN], using the namespace identifier ’ietf’ defined by [URN-NS-IETF]
and extended by [XML-Registry]:
urn:ietf:params:xml:ns:pidf
Thus, simple presence data might be thus:
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com">
<impp:tuple id="sg89ae">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<impp:contact priority="0.8">tel:+09012345678</impp:contact>
</impp:tuple>
</impp:presence>
, using a default XML namespace:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
As is generally the case in XML with namespaces, the xmlns attribute
can be used on any element in the presence information to define
either the default namespace or a namespace associated with a
namespace prefix.
4.2.3. Handling Of Unrecognized Element Names
Except as noted below, a processor of PRESENCE INFORMATION MUST
ignore any XML element with an unrecognized name (i.e., having an
unrecognized namespace URI, or an unrecognized local name within that
namespace). This includes all of the element content, even if it
appears to contain elements with recognized names.
Extensions to PIDF are informational in nature - they provide
additional information beyond <basic> status. However, in order to
understand a complex extension, nested elements within an extension
element might need to be marked as mandatory. In such cases, the
element name is qualified with a mustUnderstand=’true’ or
mustUnderstand=’1’ attribute. See section 4.3.3 for an example.
NOTE: a mustUnderstand=’true’ or mustUnderstand=’1’ attribute
within an element that is being ignored is itself ignored. The
writer of nested mandatory-to-understand information is
responsible for ensuring that any enclosing element is also
labelled with a mustUnderstand=’true’ or mustUnderstand=’1’
attribute, if necessary.
This specification defines (section 4.1) elements within the
’urn:ietf:params:xml:ns:pidf’ namespace that MUST be recognized in
CPP presence data. Processors MUST handle these as described, even
if they do not carry a mustUnderstand attribute. The XML Schema
Definition (section 4.4) indicates those elements that MUST be
present in a valid presence information document.
If an agent receives PRESENCE INFORMATION with a <status> block
containing an unrecognized element with a mustUnderstand=’true’ (or
’1’) attribute, it should treat that entire element and any content
as unrecognized and not attempt to process it.
In order to ensure that minimal implementations can correctly process
basic PIDF information the mustUnderstand attribute MUST be used only
within optional elements nested in a <status> element. This will
ensure that problems processing an extension are restricted to that
extension and do not affect the processing of the basic PIDF
information defined in this specification.
4.2.4. Status Value Extensibility
This memo defines only the <basic> status value with values of "open"
and "closed". Other status values are possible using the standard
namespace-based extensibility rules defined above.
For example, a location status value might be included thus:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:local="urn:example-com:pidf-status-type"
entity="pres:someone@example.com">
<tuple id="ub93s3">
<status>
<basic>open</basic>
<local:location>home</local:location>
</status>
<contact>im:someone@example.com</contact>
</tuple>
</presence>
Some new status values will ’extend’ the value of the <basic>
element. For example, a status value defined for use with instant
messaging may include values such as ’away’, ’busy’ and ’offline’.
In order that some level of interoperability be maintained with user
agents that don’t recognize the new extension, the <basic> status
value must also be included. This means that extensions are not
obligated to define a mapping from each of their values to OPEN or
CLOSED.
4.2.5. Standardizing Status Extensions
Although the existing PIDF definition allows arbitrary elements to
appear in the <status> element, it may be sometimes desirable to
standardize extension status elements and their semantics (the
meanings of particular statuses, how they should be interpreted).
The URN ’urn:ietf:params:xml:ns:pidf:status’ has been specified as an
umbrella namespace under which extensions to the <status> PIDF
element should be specified (e.g.,
urn:ietf:params:xml:ns:pidf:status:my-extension). New values under
this namespace MUST be defined by a standards-track RFC.
The following example XML Schema defines an extension for <location>
presence information, which can have the values of ’home’, ’office’,
or ’car’. If the <location> element were standardized, this document
would be made available in an RFC along with information about the
use of the extension. These extensions should use the namespace
’urn:ietf:params:xml:ns:pidf:status’, and each RFC defining an
extension should register an extension name within that namespace
with IANA.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:status"
xmlns:tns="urn:ietf:params:xml:ns:pidf:status"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:simpleType name="location">
<xs:restriction base="xs:string">
<xs:enumeration value="home"/>
<xs:enumeration value="office"/>
<xs:enumeration value="car"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
In addition to the XML Schema to validate the extension, registration
of the extension name with IANA, RFCs defining extensions MUST
discuss:
- The domain of applicability of the extension. Is this extension
exclusively valuable to IM clients, telephones, geolocators, etc?
What sorts of presence applications would use this extension and
under what circumstances?
- Semantics for the presence states defined in the extension. What
disposition provokes an automated presentity to declare that it is
in state X, or does a human select X from a drag-down menu? Is
there any general guidance for watchers of presence information
with state Y (for example, how they should best attempt to
communicate with the presentity, if at all, when the principal is
in state Y).
Extensions SHOULD also discuss:
- How, if at all, any presence states defined in the extension
related to <basic>, or to any relevant extension previously
published in an RFC. For example, "state Z implies OPEN, so it
MUST NOT be used if a basic state of CLOSED is expressed", or
"you should use the extension in this document, not the extension
in RFC QQQQ, if your circumstances are as follows...."
4.3. Examples
4.3.1. Default Namespace with Status Extensions
The following instance document uses a hypothetical ’pidf:im’ XML
namespace as an example of the sort of status extension that might be
developed for PIDF.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:im="urn:ietf:params:xml:ns:pidf:im"
xmlns:myex="http://id.example.com/presence/"
entity="pres:someone@example.com">
<tuple id="bs35r9">
<status>
<basic>open</basic>
<im:im>busy</im:im>
<myex:location>home</myex:location>
</status>
<contact priority="0.8">im:someone@mobilecarrier.net</contact>
<note xml:lang="en">Don’t Disturb Please!</note>
<note xml:lang="fr">Ne derangez pas, s’il vous plait</note>
<timestamp>2001-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="eg92n8">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">mailto:someone@example.com</contact>
</tuple>
<note>I’ll be in Tokyo next week</note>
</presence>
4.3.2. Presence with Other Extension Elements
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
xmlns:myex="http://id.example.com/presence/"
entity="pres:someone@example.com">
<impp:tuple id="ck38g9">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<myex:mytupletag>Extended value in tuple</myex:mytupletag>
<impp:contact priority="0.65">tel:+09012345678</impp:contact>
</impp:tuple>
<impp:tuple id="md66je">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<impp:contact priority="1.0">
im:someone@mobilecarrier.net</impp:contact>
</impp:tuple>
<myex:mytag>My extended presentity information</myex:mytag>
</impp:presence>
4.3.3. Example Mandatory To Understand Elements
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
xmlns:myex="http://id.mycompany.com/presence/"
entity="pres:someone@example.com">
<impp:tuple id="tj25ds">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<myex:complexExtension>
<myex:ex1 impp:mustUnderstand="1">val1</myex:ex1>
<myex:ex2>val2</myex:ex2>
</myex:complexExtension>
<impp:contact priority="0.725">tel:+09012345678</impp:contact>
</impp:tuple>
<myex:mytag>My extended presentity information</myex:mytag>
</impp:presence>
Here, <myex:ex1> must be understood and, if it is not recognized,
<myex:complexExtension> MUST be ignored. <myex:mytag> and
<myex:ex2> MAY be ignored if they are not recognized.
4.4. XML Schema Definitions
This section gives the XML Schema Definition [XMLSchema1] of the
"application/pidf+xml" format. This is presented as a formal
definition of the "application/pidf+xml" format. Note that the XML
Schema definition is not intended to be used with on-the-fly
validation of the presence XML document.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf"
xmlns:tns="urn:ietf:params:xml:ns:pidf"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="presence" type="tns:presence"/>
<xs:complexType name="presence">
<xs:sequence>
<xs:element name="tuple" type="tns:tuple" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="note" type="tns:note" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="tuple">
<xs:sequence>
<xs:element name="status" type="tns:status"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="contact" type="tns:contact" minOccurs="0"/>
<xs:element name="note" type="tns:note" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
<xs:complexType name="status">
<xs:sequence>
<xs:element name="basic" type="tns:basic" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="basic">
<xs:restriction base="xs:string">
<xs:enumeration value="open"/>
<xs:enumeration value="closed"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="contact">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="priority" type="tns:qvalue"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="note">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="qvalue">
<xs:restriction base="xs:decimal">
<xs:pattern value="0(.[0-9]{0,3})?"/>
<xs:pattern value="1(.0{0,3})?"/>
</xs:restriction>
</xs:simpleType>
<!-- Global Attributes -->
<xs:attribute name="mustUnderstand" type="xs:boolean" default="0">
<xs:annotation>
<xs:documentation>
This attribute may be used on any element within an optional
PIDF extension to indicate that the corresponding element must
be understood by the PIDF processor if the enclosing optional
element is to be handled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:schema>
5. IANA Considerations
This memo calls for IANA to:
- register a new MIME content-type application/pidf+xml, per [MIME],
- register a new XML namespace URN per [XML-Registry].
- register a new XML namespace URN for status extensions per [XML-
Registry].
The registration templates for these are below. For more information
on status extensions, see section 4.2.5.
5.1. Content-type registration for ’application/pidf+xml’
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pidf+xml
MIME media type name: application
MIME subtype name: pidf+xml
Required parameters: (none)
Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is
UTF-8.
Encoding considerations:
Uses XML, which can employ 8-bit characters, depending on the
character encoding used. See RFC 3023 [RFC 3023], section 3.2.
Security considerations:
This content type is designed to carry presence data, which may be
considered private information. Appropriate precautions should be
adopted to limit disclosure of this information.
Interoperability considerations:
This content type provides a common format for exchange of
presence information across different CPP compliant protocols.
Published specification:
RFC 3863
Applications which use this media type:
Presence and instant messaging systems.
Additional information:
Magic number(s): File extension(s): Macintosh File Type Code(s):
Person & email address to contact for further information:
Hiroyasu Sugano EMail: sugano.h@jp.fujitsu.com
Intended usage:
LIMITED USE
Author/Change controller:
This specification is a work item of the IETF IMPP working group,
with mailing list address <impp@iastate.edu>.
Other information:
This media type is a specialization of application/xml [RFC 3023],
and many of the considerations described there also apply to
application/pidf+xml.
5.2. URN sub-namespace registration for ’urn:ietf:params:xml:ns:pidf’
URI
urn:ietf:params:xml:ns:pidf
Description:
This is the XML namespace URI for XML elements defined by RFC 3863
to describe CPP presence information in application/pidf+xml
content type.
Registrant Contact
IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
XML
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=utf-8"/>
<title>Namespace for CPP presence information</title>
</head>
<body>
<h1>Namespace for CPP presence information</h1>
<h2>urn:ietf:params:xml:ns:pidf</h2>
<p>See <a
href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
RFC3863</a>.</p>
</body>
</html>
END
5.3. URN sub-namespace registration for
’urn:ietf:params:xml:ns:pidf:status’
URI
urn:ietf:params:xml:ns:pidf:status
Description:
This is the XML namespace URI for XML elements defined by
RFC 3863 to describe extensions to the status of CPP presence
information in application/pidf+xml content type.
Registrant Contact
IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
XML
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=utf-8"/>
<title>Namespace for CPP status extensions</title>
</head>
<body>
<h1>Namespace for CPP presence information extensions</h1>
<h2>urn:ietf:params:xml:ns:pidf:status</h2>
<p>See <a
href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
RFC3863</a>.</p>
</body>
</html>
END
6. Security Considerations
Because presence is very privacy-sensitive information, the protocol
for the presence information MUST have capabilities to protect PIDF
from possible threats, such as eavesdropping, corruption, tamper and
replay attacks. These security mechanisms must be able to be used
end-to-end between presentities and watchers, even if the watcher and
the presentity employ different presence protocols and communicate
through a CPP gateway. Since the ’application/pidf+xml’ MIME type is
defined for this PIDF document, staging security for PIDF at the MIME
level (with S/MIME [RFC3851]) seems appropriate. Therefore, PIDF
should follow the normative recommendations for the use of S/MIME
(including minimum ciphersuites) given in the core CPP specification.
Note that the use of timestamps in PIDF (see section 4.1.7) can
provide some rudimentary protection against replay attacks. If a
watcher receives presence information that is outdated, it SHOULD be
ignored. A watcher can determine that presence information is
outdated in a number of fashions. Most significantly, if the newest
timestamp in presence information is older than the newest timestamp
in the last received presence information, it should be considered
outdated. Applications and protocols also are advised to adopt their
own rules for determining how frequently presence information should
be refreshed. For example, if presence information appears to be
more than one hour old, it could be considered outdated (a
notification generated for this presence information will not take
such a long time to reach a watcher, and if a presentity has not
refreshed its presence state in the last hour, it is probably
offline).
7. Internationalization Considerations
All the processors conformant to this specification MUST be able to
generate and accept UTF-8 encoding, this being one of the mandatory
character encodings for XML conforming processors, and also required
by the policies set out in RFC 2277 [RFC2277].
Other character encodings MAY be accepted (but CPP compliant
processors are strongly discouraged from emitting anything other than
UTF-8).
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E.
Maler, "Extensible Markup Language (XML) 1.0 (Second
Edition)", W3C Recommendation, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996.
Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for