< draft-ietf-impp-cpim-pidf-07.txt   draft-ietf-impp-cpim-pidf-08.txt >
Network Working Group H. Sugano Network Working Group H. Sugano
INTERNET-DRAFT S. Fujimoto INTERNET-DRAFT S. Fujimoto
Fujitsu Fujitsu
G. Klyne G. Klyne
Baltimore Technologies Nine by Nine
A. Bateman A. Bateman
VisionTech VisionTech
W. Carr W. Carr
Intel Intel
J. Peterson J. Peterson
NeuStar NeuStar
Expires: June 2003 December 2002 Expires: November 2003 May 2003
Common Presence and Instant Messaging (CPIM) Presence Information Data Format (PIDF)
Presence Information Data Format <draft-ietf-impp-cpim-pidf-08.txt>
<draft-ietf-impp-cpim-pidf-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 47 skipping to change at page 1, line 46
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Please send comments to the authors or to the impp@iastate.edu Please send comments to the authors or to the impp@iastate.edu
discussion list. discussion list.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo specifies the Common Presence and Instant Messaging (CPIM) This memo specifies the Common Profile for Presence (CPP) Presence
Presence Information Data Format (PIDF) as a common presence data Information Data Format (PIDF) as a common presence data format for
format for CPIM-compliant Instant Messaging and Presence protocols, CPP-compliant Presence protocols, and also defines a new media type
and also defines a new media type "application/cpim-pidf+xml" to "application/pidf+xml" to represent the XML MIME entity for PIDF.
represent the XML MIME entity for PIDF.
Table of Content Table of Content
1. Introduction ......................................... 4 1. Introduction ......................................... 4
1.1. Terminology and Conventions .......................... 4 1.1. Terminology and Conventions .......................... 4
2. Design Decisions ..................................... 5 2. Design Decisions ..................................... 4
2.1. Minimal Model ........................................ 5 2.1. Minimal Model ........................................ 5
2.2. Added Features ....................................... 6 2.2. Added Features ....................................... 5
2.3. XML Encoding Decision ................................ 6 2.3. XML Encoding Decision ................................ 6
3. Overview of Presence Information Data Format ......... 7 3. Overview of Presence Information Data Format ......... 6
3.1. The 'application/cpim-pidf+xml' Content Type ......... 7 3.1. The 'application/pidf+xml' Content Type .............. 6
3.2. Presence Information Contents ........................ 7 3.2. Presence Information Contents ........................ 7
4. XML-encoded Presence Data Format ..................... 7 4. XML-encoded Presence Data Format ..................... 7
4.1. XML Format Definitions ............................... 8 4.1. XML Format Definitions ............................... 7
4.1.1. The <presence> element ............................... 8 4.1.1. The <presence> element ............................... 7
4.1.2. The <tuple> element .................................. 8 4.1.2. The <tuple> element .................................. 8
4.1.3. The <status> element ................................. 9 4.1.3. The <status> element ................................. 9
4.1.4. The <basic> element .................................. 10 4.1.4. The <basic> element .................................. 9
4.1.5. The <contact> element ................................ 10 4.1.5. The <contact> element ................................ 10
4.1.6. The <note> element ................................... 10 4.1.6. The <note> element ................................... 10
4.1.7. The <timestamp> element .............................. 11 4.1.7. The <timestamp> element .............................. 11
4.2. Presence Information Extensibility ................... 11 4.2. Presence Information Extensibility ................... 11
4.2.1. XML Namespaces Background ............................ 11 4.2.1. XML Namespaces Background ............................ 11
4.2.2. XML Namespaces In Presence Information ............... 12 4.2.2. XML Namespaces In Presence Information ............... 12
4.2.3. Handling Of Unrecognized Element Names ............... 13 4.2.3. Handling Of Unrecognized Element Names ............... 13
4.2.4. Status Value Extensibility ........................... 14 4.2.4. Status Value Extensibility ........................... 14
4.2.5. Standardizing Status Extensions ...................... 15 4.2.5. Standardizing Status Extensions ...................... 14
4.3. Examples ............................................. 16 4.3. Examples ............................................. 16
4.3.1. Default Namespace with Status Extensions ............. 16 4.3.1. Default Namespace with Status Extensions ............. 16
4.3.2. Presence with Other Extension Elements ............... 16 4.3.2. Presence with Other Extension Elements ............... 16
4.3.3. Example Mandatory To Understand Elements ............. 17 4.3.3. Example Mandatory To Understand Elements ............. 17
4.4. XML Schema Definitions ............................... 17 4.4. XML Schema Definitions ............................... 17
5. IANA Considerations .................................. 19 5. IANA Considerations .................................. 19
5.1. Content-type registration for 5.1. Content-type registration for
'application/cpim-pidf+xml' .................. 20 'application/pidf+xml' .................... 20
5.2. URN sub-namespace registration for 5.2. URN sub-namespace registration for
'urn:ietf:params:xml:ns:cpim-pidf' ........... 21 'urn:ietf:params:xml:ns:pidf' ............. 21
5.3. URN sub-namespace registration for 5.3. URN sub-namespace registration for
'urn:ietf:params:xml:ns:cpim-pidf:status' .... 22 'urn:ietf:params:xml:ns:pidf:status' ...... 22
6. Security Considerations .............................. 22 6. Security Considerations .............................. 22
7. Internationalization Considerations .................. 23 7. Internationalization Considerations .................. 23
8. Normative References ................................. 23 8. Normative References ................................. 23
9. Informative References ............................... 24 9. Informative References ............................... 24
10. Authors' Addresses .................................. 25 10. Authors' Addresses .................................. 25
11. Appendix A. Document Type Definitions ............... 26 11. Appendix A. Document Type Definitions ............... 26
12. Full Copyright Statement ............................ 27 12. Full Copyright Statement ............................ 27
1. Introduction 1. Introduction
The Common Profile for Instant Messaging (CPIM) specifications define The Common Profiles for Instant Messaging (CPIM) [CPIM] and Presence
a set of common operations and various formats to achieve (CPP) [CPP] specifications define a set of operations and parameters
interoperability between different Instant Messaging and Presence to achieve interoperability between different Instant Messaging and
protocols which meet RFC 2779 [RFC2779]. The CPIM core specification Presence protocols which meet RFC 2779 [RFC2779].
[CPIM] defines a set of common operations and their parameters to be
supported by interworking Presence and IM protocols in order to allow
straightforward gatewaying between them. The CPIM Message Format
[CPIM-MSG] defines a common format for instant messages, which
enables secure end-to-end IM exchange through the gateways.
This memo further defines the CPIM Presence Information Data Format This memo further defines the Presence Information Data Format (PIDF)
(PIDF) as a common presence data format for CPIM-compliant presence as a common presence data format for CPP-compliant presence
protocols. The significance of the common presence format primarily protocols, allowing presence information to be transferred across
resides in the fact that it alleviates the load of gatewaying of CPP-compliant protocol boundaries without modification, with
messages with presence data payloads. Without such a common presence attendant benefits for security and performance.
data format, a gateway must process and transform the presence data
payload from one format to another every time it gateways the
protocol messages. Such payload processing also disables the
validity of digitally signed presence data. Utilizing the common
presence data format allows secure transfer of the presence payloads
across the boundary of different protocol domains.
The format specified in this memo is intended to define the base The format specified in this memo defines the base presence format
presence format and extensibility required by RFC 2779. It only and extensibility required by RFC 2779. It defines a minimal set of
defines a minimal set of presence status values defined by the IMPP presence status values defined by the IMPP Model document [RFC2778].
Model document [RFC2778]. However, a presence application is able to However, a presence application is able to define its own status
define its own status values using the extensibility framework values using the extensibility framework provided by this memo.
provided by this memo. Defining such extended status values is Defining such extended status values is beyond the scope of this
beyond the scope of this memo. memo.
Note also that this memo defines only the format for a presence data Note also that this memo defines only the format for a presence data
payload and the extensibility framework for it. How the presence data payload and the extensibility framework for it. How the presence data
is transferred within a specific protocol frame would be defined is transferred within a specific protocol frame would be defined
separately in a protocol specification. separately in a protocol specification.
1.1. Terminology and Conventions 1.1. Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model This memo makes use of the vocabulary defined in the IMPP Model
document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN,
PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the
memo are used in the same meaning as defined therein. memo are used in the same meaning as defined therein.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 [RFC2119]. interpreted as described in RFC 2119 [RFC2119].
[[[Editorial comments and questions about outstanding issues are
provided in triple brackets like this. These working comments should
be resolved and removed prior to final publication.]]]
2. Design Decisions 2. Design Decisions
We have adopted the IMPP Model and Requirements documents [RFC2778, We have adopted the IMPP Model and Requirements documents [RFC2778,
RFC2779] as the starting point of our discussion. The two RFCs RFC2779] as the starting point of our discussion. The two RFCs
contains a number of statements about presence information, which can contain a number of statements about presence information, which can
be regarded as a basic set of constraints for the format design. be regarded as a basic set of constraints for the format design.
Also, we took the minimalist approach to the design based on them. Also, we took the minimalist approach to the design based on them.
Starting from the minimal model, only the features that are necessary Starting from the minimal model, only the features that are necessary
to solve particular problems have been combined. to solve particular problems have been included.
2.1. Minimal Model 2.1. Minimal Model
This specification is based on the minimal model extracted from the This specification is based on the minimal model extracted from the
IMPP Model and Requirements documents. The model consists of the IMPP Model and Requirements documents. The model consists of the
following items. Each of them is accompanied with the corresponding following items. Each of them is accompanied with the corresponding
RFCs and their section numbers as its grounds, e.g. (RFC2778:Sec.2.4) RFCs and their section numbers as its grounds, e.g. (RFC2778:Sec.2.4)
refers to Section 2.4 of RFC 2778. refers to Section 2.4 of RFC 2778.
(a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES, (a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES,
where a PRESENCE TUPLE consists of a STATUS, an optional where a PRESENCE TUPLE consists of a STATUS, an optional
COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP.
Note that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is Note that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is
understood more narrowly in this document to refer only to a understood in this document to refer only to a URI.
URI. (RFC2778:Sec.3) (RFC2778:Sec.3)
(b) STATUS has at least the mutually-exclusive values OPEN and (b) STATUS has at least the mutually-exclusive values OPEN and
CLOSED, which have meaning for the acceptance of INSTANT CLOSED, which have meaning for the acceptance of INSTANT
MESSAGES, and may have meaning for other COMMUNICATION MEANS. MESSAGES, and may have meaning for other COMMUNICATION MEANS.
There may be other values of STATUS that do not imply anything There may be other values of STATUS that do not imply anything
about INSTANT MESSAGE acceptance. These other values of STATUS about INSTANT MESSAGE acceptance. These other values of STATUS
may be combined with OPEN and CLOSED or they may be mutually- may be combined with OPEN and CLOSED or they may be mutually-
exclusive with those values. (RFC2778:Sec.3, RFC2779:Sec.4.4.1- exclusive with those values. (RFC2778:Sec.3, RFC2779:Sec.4.4.1-
4.4.3) 4.4.3)
(c) STATUS may consist of single or multiple values. (RFC2778:Sec.2.4) (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 (d) There must be a means of extending the common presence format
to represent additional information not included in the common to represent additional information not included in the common
format. The extension and registration mechanisms must be format. The extension and registration mechanisms must be
defined for presence information schema, including new STATUS defined for presence information schema, including new STATUS
conditions and new forms for OTHER PRESENCE MARKUP. (RFC2779: conditions and new forms for OTHER PRESENCE MARKUP. (RFC2779:
Sec.3.1.4-3.1.5) Sec.3.1.4-3.1.5)
(e) The common presence format must include a means to uniquely (e) The common presence format must include a means to uniquely
identify the PRESENTITY whose PRESENCE INFORMATION is reported. identify the PRESENTITY whose PRESENCE INFORMATION is reported.
skipping to change at page 6, line 20 skipping to change at page 6, line 5
presence information sent to a WATCHER. The format must allow presence information sent to a WATCHER. The format must allow
integrity, confidentiality and authentication properties to be integrity, confidentiality and authentication properties to be
applied to presence information. (RFC2779:Sec5.2.1, 5.2.4, 5.3.1, applied to presence information. (RFC2779:Sec5.2.1, 5.2.4, 5.3.1,
5.3.3) 5.3.3)
2.2. Added Features 2.2. Added Features
In addition to the minimal model described above, the format In addition to the minimal model described above, the format
specified in this specification has the following features. specified in this specification has the following features.
(a) Relative priorities of contact addresses should be specifiable (a) Relative priorities of contact addresses are specifiable in
in order to allow the source of PRESENCE INFORMATION to tell the order to allow the source of PRESENCE INFORMATION to tell the
receiver (WATCHER USER AGENTS) its preference over multiple contact receiver (WATCHER USER AGENTS) its preference over multiple
means. contact means.
(b) The presence format should be able to contain the timestamp of (b) The presence format is able to contain the timestamp of the
the creation of the PRESENCE INFORMATION. The timestamp in the creation of the PRESENCE INFORMATION. The timestamp in the
presence document lets the receiver know the time of the creation presence document lets the receiver know the time of the creation
of the data even if the message containing it arrives late for of the data even if the message containing it is delayed.
some reason. It can also be used to detect a replay attack, It can also be used to detect a replay attack, independent of
independent of the underlying signature mechanism. Note that the underlying signature mechanism. Note that this mechanism
this mechanism does not assume any global time synchronization does not assume any global time synchronization system for
system for watchers and presentities (see Appendix A of RFC2779, watchers and presentities (see Appendix A of RFC2779, 8.1.4 A7),
8.1.4 A7), but rather assumes that the minimum length of time but rather assumes that the minimum length of time that might
that might pass before presence information is considered stale pass before presence information is considered stale is long
is long enough that minor variations among system clocks will not enough that minor variations among system clocks will not lead
lead to misjudgments of the freshness of presence information." to misjudgments of the freshness of presence information.
2.3. XML Encoding Decision 2.3. XML Encoding Decision
The CPIM Presence Information Data Format encodes presence The Presence Information Data Format encodes presence information in
information in XML (eXtensible Markup Language [XML]), which is XML (eXtensible Markup Language [XML]). Regarding the features of
rapidly gaining broad acceptance as a syntactic framework to encode PRESENCE INFORMATION discussed above, such that it has a hierarchical
structured data transferred over the Internet. Regarding the structure and it should be fully extensible, XML is considered as the
features of PRESENCE INFORMATION discussed above, such that it has a most desirable framework over other candidates such as vCard
hierarchical structure and it should be fully extensible, XML is [RFC2426].
considered as the most desirable framework over other candidates such
as vCard [RFC2426].
3. Overview of Presence Information Data Format 3. Overview of Presence Information Data Format
This section describes an overview of the presence data format This section describes an overview of the presence data format
defined in this memo. defined in this memo.
3.1. The 'application/cpim-pidf+xml' Content Type 3.1. The 'application/pidf+xml' Content Type
This memo defines a new content type "application/cpim-pidf+xml" for This memo defines a new content type "application/pidf+xml" for an
an XML MIME entity that encodes presence information conformant to XML MIME entity that contains presence information. This
this specification. This specification follows the recommendations specification follows the recommendations and conventions described
and conventions described in [RFC3023], including the naming in [RFC3023], including the naming convention of the type ('+xml'
convention of the type ('+xml' suffix) and the usage of the 'charset' suffix) and the usage of the 'charset' parameter.
parameter.
Although it is defined as optional, use of the 'charset' parameter is Although it is defined as optional, use of the 'charset' parameter is
STRONGLY RECOMMENDED. If the 'charset' parameter is not specified, RECOMMENDED. If the 'charset' parameter is not specified, conforming
conforming XML processors to [XML] MUST follow the requirements in XML processors MUST follow the requirements in section 4.3.3 of
section 4.3.3 of [XML]. [XML].
3.2. Presence Information Contents 3.2. Presence Information Contents
This subsection outlines the information in an "application/cpim- This subsection outlines the information in an "application/pidf+xml"
pidf+xml" document. A full definition of the PIDF content is in document. A full definition of the PIDF content is in Section 4.
Section 4.
o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY. o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY.
o List of presence tuples o List of PRESENCE TUPLES
- Status: OPEN/CLOSED for Instant Messaging or status for - Identifier: token to identify this tuple within the presence
other communication means. information.
- Communication address: communication means and contact - STATUS: OPEN/CLOSED and/or extension status values.
address of this tuple. (optional) - COMMUNICATION ADDRESS: COMMUNICATION MEANS and CONTACT
ADDRESS of this tuple. (optional)
- Relative priority: numerical value specifying the priority - Relative priority: numerical value specifying the priority
of this communication address. (optional) of this COMMUNICATION ADDRESS. (optional)
- Timestamp: timestamp of the change of this tuple.(optional) - Timestamp: timestamp of the change of this tuple.(optional)
- Human readable comment: free text memo about this tuple - Human readable comment: free text memo about this tuple
(optional) (optional)
o PRESENTITY human readable comment: free text memo about the o PRESENTITY human readable comment: free text memo about the
PRESENTITY (optional). PRESENTITY (optional).
4. XML-encoded Presence Data Format 4. XML-encoded Presence Data Format
This section defines an XML-encoded presence information data format This section defines an XML-encoded presence information data format
(PIDF) for use with CPIM compliant systems. A presence payload in (PIDF) for use with CPP compliant systems. A presence payload in
this format is expected to be produced by the PRESENTITY (the source this format is expected to be produced by the PRESENTITY (the source
of the PRESENCE INFORMATION) and transported to the WATCHERS by the of the PRESENCE INFORMATION) and transported to the WATCHERS by the
presence servers or gateways without any interpretation or presence servers or gateways without any interpretation or
modification. modification.
4.1. XML Format Definitions 4.1. XML Format Definitions
A PIDF object is a well formed XML document. A PIDF object is a well formed XML document.
It MUST have the XML declaration and it SHOULD contain an encoding It MUST have the XML declaration and it SHOULD contain an encoding
declaration in the XML declaration, e.g. "<?XML version='1.0' declaration in the XML declaration, e.g. "<?xml version='1.0'
encoding='UTF-8'?>". If the charset parameter of the MIME content encoding='UTF-8'?>". If the charset parameter of the MIME content
type declaration is present and it is different from the encoding type declaration is present and it is different from the encoding
declaration, the charset parameter takes precedence. declaration, the charset parameter takes precedence.
Every application conformant to this specification MUST accept the Every application conformant to this specification MUST accept the
UTF-8 character encoding to ensure the minimal interoperability. UTF-8 character encoding to ensure the minimal interoperability.
4.1.1. The <presence> element 4.1.1. The <presence> element
The root element of the "application/cpim-pidf+xml" object is defined PIDF elements are associated with the XML namespace name
as <presence>. This element contains any number (including 0) of 'urn:ietf:params:xml:ns:pidf', declared using an xmlns attribute, per
<tuple> elements, followed by any number (including 0) of <note>
elements, followed by any number of OPTIONAL extension elements from [XML-NS]. The namespace may be a default namespace, or may be
other namespaces. 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 <presence> element MUST have an 'entity' attribute. The value of
the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing
this presence document. this presence document.
The <presence> element MUST contain a namespace declaration ('xmlns') The <presence> element MUST contain a namespace declaration ('xmlns')
to indicate the namespace on which the presence document is based. to indicate the namespace on which the presence document is based.
The presence document compliant to this specification MUST have the The presence document compliant to this specification MUST have the
namespace 'urn:ietf:params:xml:ns:cpim-pidf:'. namespace 'urn:ietf:params:xml:ns:pidf:'.
It MAY contain other namespace declarations for the extensions used It MAY contain other namespace declarations for the extensions used
in the presence XML document. in the presence XML document.
4.1.2. The <tuple> element 4.1.2. The <tuple> element
The <tuple> element is used to carry a piece of PRESENCE INFORMATION The <tuple> element carries a PRESENCE TUPLE, consisting of a
defined as PRESENCE TUPLE in RFC2778. Thus, it contains one
mandatory <status> element, followed by any number of OPTIONAL mandatory <status> element, followed by any number of OPTIONAL
extension elements from other namespaces, followed by one OPTIONAL extension elements (possibly from other namespaces), followed by an
<contact> elements, followed by any number of OPTIONAL <note> OPTIONAL <contact> element, followed by any number of OPTIONAL <note>
elements, followed by one OPTIONAL <timestamp> elements. elements, followed by an OPTIONAL <timestamp> element.
Tuples provide a way of segmenting presence information. Protocols or Tuples provide a way of segmenting presence information. Protocols or
applications may choose to segment the presence information applications may choose to segment the presence information
associated with a presentity for any number of reasons - for example, associated with a presentity for any number of reasons - for example,
because components of the full presence information for a presentity because components of the full presence information for a presentity
have come from distinct devices or different applications on the same have come from distinct devices or different applications on the same
device, or have been generated at different times. Tuples should be device, or have been generated at different times. Tuples should be
preferred over other manners of segmenting presence information such preferred over other manners of segmenting presence information such
as creating multiple PIDF instances. as creating multiple PIDF instances.
The <tuple> element MUST contain an 'id' attribute which is used to The <tuple> element MUST contain an 'id' attribute which is used to
distinguish this tuple from other tuples in the same XML document. distinguish this tuple from other tuples in the same PRESENTITY. The
The value of an 'id' attribute MUST be unique within 'id' attribute value of an 'id' attribute MUST be unique within 'id' attribute
values of other tuples in the same document. An 'id' value is used values of other tuples for the same PRESENTITY. An 'id' value is
by applications processing the presence document to identify the used by applications processing the presence document to identify the
corresponding tuple in the previously acquired PRESENCE INFORMATION corresponding tuple in the previously acquired PRESENCE INFORMATION
of the same PRESENTITY. The value of the 'id' attribute SHOULD be of the same PRESENTITY. The value of the 'id' attribute is an
treated as just a CDATA value (no semantics). 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 The <contact> element is OPTIONAL because a PRESENTITY might need to
hide its COMMUNICATION ADDRESS or there might be tuples not related hide its COMMUNICATION ADDRESS or there might be tuples not related
to any COMMUNICATION MEANS. Tuples that contain a <basic> status to any COMMUNICATION MEANS. Tuples that contain a <basic> status
element SHOULD contain a <contact> address. Tuples MAY contain element SHOULD contain a <contact> address. Tuples MAY contain
conflicting presence status - one <tuple> might provide a <basic> conflicting presence status - one <tuple> might provide a <basic>
<status> of OPEN, and another <tuple> in the same PIDF could contain <status> of OPEN, and another <tuple> in the same PIDF could contain
a <basic> <status> of CLOSED, even if they both contain the same a <basic> <status> of CLOSED, even if they both contain the same
<contact> address. <contact> address.
skipping to change at page 9, line 43 skipping to change at page 9, line 28
absence of any application-specific or protocol-specific absence of any application-specific or protocol-specific
understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey
the following guidelines. WATCHER USER AGENTS should note which the following guidelines. WATCHER USER AGENTS should note which
tuples in the PIDF have changed their state since the last tuples in the PIDF have changed their state since the last
notification by correlating the 'id' of each <tuple> with those notification by correlating the 'id' of each <tuple> with those
received in previous notifications and comparing both <status> values received in previous notifications and comparing both <status> values
and <timestamp> elements in the tuples, if any are present. and <timestamp> elements in the tuples, if any are present.
4.1.3. The <status> element 4.1.3. The <status> element
The <status> element contains one OPTIONAL <basic> elements, followed The <status> element contains one OPTIONAL <basic> element, followed
by any number of OPTIONAL extension elements from other namespaces, by any number of OPTIONAL extension elements (possibly from other
under the restriction that at least one child element appears in the namespaces), under the restriction that at least one child element
<status> element. These children elements of <status> contain status appears in the <status> element. These children elements of <status>
values of this tuple. By allowing multiple status values in a single contain status values of this tuple. By allowing multiple status
<tuple> element, different types of status values, e.g. reachability values in a single <tuple> element, different types of status values,
and location, can be represented by a <tuple>. See Section 4.3 for an e.g. reachability and location, can be represented by a <tuple>. See
example with multiple status values. Section 4.3 for an example with multiple status values.
This memo only defines the <basic> status value element. Other status This memo only defines the <basic> status value element. Other status
values may be included using the standard extensibility framework values may be included using the standard extensibility framework
(see Section 4.2.4). Applications encountering unrecognized elements (see Section 4.2.4). Applications encountering unrecognized elements
within <status> may ignore them, unless they carry a within <status> may ignore them, unless they carry a
mustUnderstand="true" or mustUnderstand="1" attribute (see section mustUnderstand="true" or mustUnderstand="1" attribute (see section
4.2.3). 4.2.3).
Note that, while the <status> element MUST have at least one status Note that, while the <status> element MUST have at least one status
value element, this status value may not be the <basic> element. value element, this status value might not be the <basic> element.
4.1.4. The <basic> element 4.1.4. The <basic> element
The <basic> element contains one of the following strings: "open" or The <basic> element contains one of the following strings: "open" or
"closed". The values "open" and "closed" has the same meaning as "closed".
OPEN and CLOSED defined in RFC 2778 respectively, and stand for
availability of receiving instant messages if the <tuple> is for an The values "open" and "closed" indicate availability to receive
instant messaging address. They also have meanings of general INSTANT MESSAGES if the <tuple> is for an instant messaging address.
availability for other communication means. But, this memo does not They also indicate general availability for other communication
specify them in detail. 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 4.1.5. The <contact> element
The <contact> element contains a URL of the contact address. It The <contact> element contains a URL of the contact address. It
optionally has a 'priority' attribute, whose value means a relative optionally has a 'priority' attribute, whose value means a relative
priority of this contact address over the others. The value of the 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 attribute MUST be a decimal number between 0 and 1 inclusive with at
most 3 digits after the decimal point. Higher values indicate higher 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. Examples of priority values are 0, 0.021, 0.5, 1.00. If the
'priority' attribute is omitted, applications MUST understand that 'priority' attribute is omitted, applications MUST assign the contact
the contact address has the lowest priority. If the 'priority' value address the lowest priority. If the 'priority' value is out of the
is out of the range, applications just SHOULD ignore the value and range, applications just SHOULD ignore the value and process it as if
process it as if the attribute was not present. the attribute was not present.
It is RECOMMENDED that applications handles a contact with higher Applications SHOULD handle contacts with a higher priority as they
priority than another one so that the priority is recognizable by have precedence over those with lower priorities. How they are
users. How to handle contacts with the same priority is up to actually treated is beyond this specification. Also, how to handle
implementations. contacts with the same priority is up to implementations.
4.1.6. The <note> element 4.1.6. The <note> element
The <note> element contains a string value, which is usually used for The <note> element contains a string value, which is usually used for
a human readable comment. A <note> element MAY appear as a child a human readable comment. A <note> element MAY appear as a child
element of <presence> or as a child element of the <tuple> element. 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 In the former case the comment is about the PRESENTITY and in the
latter case, the comment is regarding the particular tuple. latter case the comment is regarding the particular tuple.
Note that, wherever it appears, a <note> element SHOULD NOT be used, Note that, wherever it appears, a <note> element SHOULD NOT be used,
and interpreted, as a non-interoperable substitute for status of its and interpreted, as a non-interoperable substitute for status of its
parent element. parent element.
The <note> element SHOULD have a special attribute 'xml:lang' to The <note> element SHOULD have a special attribute 'xml:lang' to
specify the language used in the contents of this element as defined 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 in Section 2.12 of [XML]. The value of this attribute is the
language indentifier as defined by [RFC1766]. It MAY be omitted when language identifier as defined by [RFC3066]. It MAY be omitted when
the language used is implied by the larger context such as the the language used is implied by the larger context such as the
encoding information of the contents, such as an xml:lang attribute 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 XML element, or a Content-language header [RFC3282]
on an enclosing MIME wrapper. on an enclosing MIME wrapper.
4.1.7. The <timestamp> element 4.1.7. The <timestamp> element
The <timestamp> element contains a string indicating the date and The <timestamp> element contains a string indicating the date and
time of the status change of this tuple. The value of this element time of the status change of this tuple. The value of this element
MUST follow the IMPP datetime format [RFC3339]. Timestamps that MUST follow the IMPP datetime format [RFC3339]. Timestamps that
contain 'T' or 'Z' MUST use the capitalized forms. contain 'T' or 'Z' MUST use the capitalized forms.
As a security measure, the <timestamp> element SHOULD be included in As a security measure, the <timestamp> element SHOULD be included in
all tuples unless the exact time of the status change cannot be all tuples unless the exact time of the status change cannot be
determined. For security guidelines for watchers receiving presence determined. For security guidelines for watchers receiving presence
information with timestamps, see the Security Considerations. information with timestamps, see the Security Considerations.
A PRESENTITY MUST NOT generate successive <presence> elements
containing the same timestamp.
4.2. Presence Information Extensibility 4.2. Presence Information Extensibility
The presence information extensibility framework is based on XML The presence information extensibility framework is based on XML
namespaces [XML-NS]. namespaces [XML-NS].
RFC2779 requires that PIDF have a means of extending <status> values RFC2779 requires that PIDF have a means of extending <status> values
beyond <basic>. These extensions MUST NOT modify how <basic> is to be beyond <basic>. These extensions MUST NOT modify how <basic> is to be
understood, nor change the the structure or semantics of PIDF bodies understood, nor change the structure or semantics of PIDF bodies
themselves. These extensions merely allow protocols and applications themselves. These extensions merely allow protocols and applications
to define richer presence data. to define richer presence data.
4.2.1. XML Namespaces Background 4.2.1. XML Namespaces Background
All elements and some attributes are associated with a "namespace", All elements and some attributes are associated with a "namespace",
which is in turn associated with a globally unique URI. Any which is in turn associated with a globally unique URI. Any
developer can introduce their own element names, avoiding conflict by developer can introduce their own element names, avoiding conflict by
choosing an appropriate namespace URI. choosing an appropriate namespace URI.
skipping to change at page 12, line 33 skipping to change at page 12, line 32
namespace. (By "globally unique", we mean constructed according to namespace. (By "globally unique", we mean constructed according to
some set of rules so that it is reasonable to expect that nobody else some set of rules so that it is reasonable to expect that nobody else
will use the same URI for a different purpose.) will use the same URI for a different purpose.)
For further details, see the XML namespace specification [XML-NS]. For further details, see the XML namespace specification [XML-NS].
4.2.2. XML Namespaces In Presence Information 4.2.2. XML Namespaces In Presence Information
A URI used as a namespace identifier in PRESENCE INFORMATION data A URI used as a namespace identifier in PRESENCE INFORMATION data
MUST be a full absolute-URI, per RFC 2396 [URI]. (Relative URIs and MUST be a full absolute-URI, per RFC 2396 [URI]. (Relative URIs and
URI- references containing fragment identifiers MUST NOT be used for URI-references containing fragment identifiers MUST NOT be used for
this purpose.) this purpose.)
The namespace URI for elements defined by this specification is a URN The namespace URI for elements defined by this specification is a URN
[URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF]
and extended by [XML-Registry]: and extended by [XML-Registry]:
urn:ietf:params:xml:ns:cpim-pidf urn:ietf:params:xml:ns:pidf
Thus, simple presence data might be thus: Thus, simple presence data might be thus:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:cpim-pidf" <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com"> entity="pres:someone@example.com">
<impp:tuple id="sg89ae"> <impp:tuple id="sg89ae">
<impp:status> <impp:status>
<impp:basic>open</impp:basic> <impp:basic>open</impp:basic>
</impp:status> </impp:status>
<impp:contact priority="0.8">tel:09012345678</impp:contact> <impp:contact priority="0.8">tel:+09012345678</impp:contact>
</impp:tuple> </impp:tuple>
</impp:presence> </impp:presence>
or, using a default XML namespace: or, using a default XML namespace:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com"> entity="pres:someone@example.com">
<tuple id="sg89ae"> <tuple id="sg89ae">
<status> <status>
<basic>open</basic> <basic>open</basic>
</status> </status>
<contact priority="0.8">tel:09012345678</contact> <contact priority="0.8">tel:+09012345678</contact>
</tuple> </tuple>
</presence> </presence>
As is generally the case in XML, the xmlns attribute can be used on As is generally the case in XML with namespaces, the xmlns attribute
any element in the presence information to define either the default can be used on any element in the presence information to define
namespace or a namespace associated with a namespace prefix. either the default namespace or a namespace associated with a
namespace prefix.
4.2.3. Handling Of Unrecognized Element Names 4.2.3. Handling Of Unrecognized Element Names
Except as noted below, a processor of PRESENCE INFORMATION MUST Except as noted below, a processor of PRESENCE INFORMATION MUST
ignore any XML element with an unrecognized name (i.e. having an ignore any XML element with an unrecognized name (i.e. having an
unrecognized namespace URI, or an unrecognized local name within that unrecognized namespace URI, or an unrecognized local name within that
namespace). This includes all of the element content, even if it namespace). This includes all of the element content, even if it
appears to use recognized names. appears to contain elements with recognized names.
Extensions to PIDF are informational in nature - they provide Extensions to PIDF are informational in nature - they provide
additional information beyond <basic> status. However, in order to additional information beyond <basic> status. However, in order to
understand a complex extension, nested elements within an extension understand a complex extension, nested elements within an extension
element might need to be marked as mandatory. In such cases, the element might need to be marked as mandatory. In such cases, the
element name is qualified with a mustUnderstand='true' or element name is qualified with a mustUnderstand='true' or
mustUnderstand='1' attribute, which attribute name is associated with mustUnderstand='1' attribute. See section 4.3.3 for an example.
the CPIM presence namespace.See section 4.3.3 for an example.
NOTE: a mustUnderstand='true' or mustUnderstand='1' attribute NOTE: a mustUnderstand='true' or mustUnderstand='1' attribute
within an element that is being ignored is itself ignored. The within an element that is being ignored is itself ignored. The
writer of nested mandatory-to-understand information is responsible writer of nested mandatory-to-understand information is responsible
for ensuring that any enclosing element is also labelled with a for ensuring that any enclosing element is also labelled with a
mustUnderstand='true' or mustUnderstand='1' attribute, if mustUnderstand='true' or mustUnderstand='1' attribute, if
necessary. necessary.
This specification defines (section 4.1) elements within the This specification defines (section 4.1) elements within the
'urn:ietf:params:xml:ns:cpim-pidf' namespace that MUST be recognized 'urn:ietf:params:xml:ns:pidf' namespace that MUST be recognized in
in CPIM presence data. Processors MUST handle these as described, CPP presence data. Processors MUST handle these as described, even
even if they do not carry a mustUnderstand attribute. The XML Schema if they do not carry a mustUnderstand attribute. The XML Schema
Definition (section 4.4) indicates those elements that MUST be Definition (section 4.4) indicates those elements that MUST be
present in a valid presence information document. present in a valid presence information document.
If an agent receives PRESENCE INFORMATION with a <status> block If an agent receives PRESENCE INFORMATION with a <status> block
containing an unrecognized element that has a mustUnderstand='true' containing an unrecognized element with a mustUnderstand='true' (or
(or '1') attribute, it should treat the entire element as '1') attribute, it should treat that entire element and any content
unrecognized and not attempt to process it. as unrecognized and not attempt to process it.
Note that the mustUnderstand attribute MUST NOT be used in a way that In order to ensure that minimal implementations can correctly process
might prevent a minimal implementation from understanding the basic basic PIDF information the mustUnderstand attribute MUST be used only
PIDF information defined in this specification. To ensure this, the within optional elements nested in a <status> element. This will
mustUnderstand attribute MUST NOT be used outside elements within ensure that problems processing an extension are restricted to that
optional, so that non-recognition of a mandatory extension results in extension and do not affect the processing of the basic PIDF
no worse than ignoring the optional extension in which it is information defined in this specification.
contained.
4.2.4. Status Value Extensibility 4.2.4. Status Value Extensibility
This memo only defines the <basic> status value with values of "open" This memo defines only the <basic> status value with values of "open"
and "closed". Other status values are possible using the standard and "closed". Other status values are possible using the standard
namespace-based extensibility rules defined above. namespace-based extensibility rules defined above.
For example, a location status value might be included thus: For example, a location status value might be included thus:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:local="urn:example-com:pidf-status-type" xmlns:local="urn:example-com:pidf-status-type"
entity="pres:someone@example.com"> entity="pres:someone@example.com">
<tuple id="938s3w"> <tuple id="ub93s3">
<status> <status>
<basic>open</basic> <basic>open</basic>
<local:location>home</local:location> <local:location>home</local:location>
</status> </status>
<contact>im:someone@example.com</contact> <contact>im:someone@example.com</contact>
</tuple> </tuple>
</presence> </presence>
Some new status values will 'extend' the value of the <basic> Some new status values will 'extend' the value of the <basic>
element. For example, a status value defined for use with instant element. For example, a status value defined for use with instant
messaging may include values such as 'away', 'busy' and 'offline'. In messaging may include values such as 'away', 'busy' and 'offline'. In
order that some level of interoperability be maintained with user order that some level of interoperability be maintained with user
agents that don't recognise the new extension, the <basic> status agents that don't recognize the new extension, the <basic> status
value must also be included. This means that extensions are not value must also be included. This means that extensions are not
obligated to define a mapping from each of their values to OPEN or obligated to define a mapping from each of their values to OPEN or
CLOSED. CLOSED.
4.2.5. Standardizing Status Extensions 4.2.5. Standardizing Status Extensions
Although the existing PIDF definition allows arbitrary elements to Although the existing PIDF definition allows arbitrary elements to
appear in the <status> element, it may be sometimes desirable to appear in the <status> element, it may be sometimes desirable to
standardize extension status elements and their semantics (the standardize extension status elements and their semantics (the
meanings of particular statuses, how their should be interpreted). meanings of particular statuses, how they should be interpreted). The
The URN 'urn:ietf:params:xml:ns:cpim-pidf:status' has been defined as URN 'urn:ietf:params:xml:ns:pidf:status' has been defined as a
a namespace URI for extensions standardized by the IETF, and new namespace URI for extensions standardized by the IETF, and new values
values in this namespace must be defined by a standards-track RFC. in this namespace must be defined by a standards-track RFC.
The following example XML Schema defines an extension for <location> The following example XML Schema defines an extension for <location>
presence information, which can have the values of 'home', 'office', presence information, which can have the values of 'home', 'office',
or 'car'. If the <location> element were standardized, this document or 'car'. If the <location> element were standardized, this document
would be made available in an RFC along with information about the would be made available in an RFC along with information about the
use of the extension. These extensions should use the namespace use of the extension. These extensions should use the namespace
'urn:ietf:params:xml:ns:cpim-pidf:status', and each RFC defining an 'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an
extension should register an extension name within that namespace extension should register an extension name within that namespace
with IANA. with IANA.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:cpim-pidf:status" <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:status"
xmlns:tns="urn:ietf:params:xml:ns:cpim-pidf:status" xmlns:tns="urn:ietf:params:xml:ns:pidf:status"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:simpleType name="location"> <xs:simpleType name="location">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="home"/> <xs:enumeration value="home"/>
<xs:enumeration value="office"/> <xs:enumeration value="office"/>
<xs:enumeration value="car"/> <xs:enumeration value="car"/>
</xs:restriction> </xs:restriction>
skipping to change at page 16, line 23 skipping to change at page 16, line 21
published in an RFC. For example, "state Z implies OPEN, so it MUST 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 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 should use the extension in this document, not the extension in RFC
QQQQ, if your circumstances are as follows...." QQQQ, if your circumstances are as follows...."
4.3. Examples 4.3. Examples
4.3.1. Default Namespace with Status Extensions 4.3.1. Default Namespace with Status Extensions
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:im="urn:ietf:params:xml:ns:cpim-pidf:im" xmlns:im="urn:ietf:params:xml:ns:pidf:im"
xmlns:myex="http://id.example.com/cpim-presence/" xmlns:myex="http://id.example.com/presence/"
entity="pres:someone@example.com"> entity="pres:someone@example.com">
<tuple id="35bs9r"> <tuple id="bs35r9">
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>busy</im:im> <im:im>busy</im:im>
<myex:location>home</myex:location> <myex:location>home</myex:location>
</status> </status>
<contact priority="0.8">im:someone@mobilecarrier.net</contact> <contact priority="0.8">im:someone@mobilecarrier.net</contact>
<note xml:lang="en">Don't Disturb Please!</note> <note xml:lang="en">Don't Disturb Please!</note>
<note xml:lang="fr">Ne derangez pas, s'il vous plait</note> <note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
<timestamp>2001-10-27T16:49:29Z</timestamp> <timestamp>2001-10-27T16:49:29Z</timestamp>
</tuple> </tuple>
<tuple id="8eg92n"> <tuple id="eg92n8">
<status> <status>
<basic>open</basic> <basic>open</basic>
</status> </status>
<contact priority="1.0">mailto:someone@example.com</contact> <contact priority="1.0">mailto:someone@example.com</contact>
</tuple> </tuple>
<note>I'll be in Tokyo next week</note> <note>I'll be in Tokyo next week</note>
</presence> </presence>
4.3.2. Presence with Other Extension Elements 4.3.2. Presence with Other Extension Elements
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:cpim-pidf" <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
xmlns:myex="http://id.example.com/cpim-presence/" xmlns:myex="http://id.example.com/presence/"
entity="pres:someone@example.com"> entity="pres:someone@example.com">
<impp:tuple id="c38g92"> <impp:tuple id="ck38g9">
<impp:status> <impp:status>
<impp:basic>open</impp:basic> <impp:basic>open</impp:basic>
</impp:status> </impp:status>
<myex:mytupleelement>Extended value in tuple</myex:mytupleelement> <myex:mytupletag>Extended value in tuple</myex:mytupletag>
<impp:contact priority="0.65">tel:09012345678</impp:contact> <impp:contact priority="0.65">tel:+09012345678</impp:contact>
</impp:tuple> </impp:tuple>
<impp:tuple id="71md66"> <impp:tuple id="md66je">
<impp:status> <impp:status>
<impp:basic>open</impp:basic> <impp:basic>open</impp:basic>
</impp:status> </impp:status>
<impp:contact priority="1.0"> <impp:contact priority="1.0">
im:someone@mobilecarrier.net</impp:contact> im:someone@mobilecarrier.net</impp:contact>
</impp:tuple> </impp:tuple>
<myex:mytag>My extended presentity information</myex:mytag> <myex:mytag>My extended presentity information</myex:mytag>
</impp:presence> </impp:presence>
4.3.3. Example Mandatory To Understand Elements 4.3.3. Example Mandatory To Understand Elements
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:cpim-pidf" <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
xmlns:myex="http://id.mycompany.com/cpim-presence/" xmlns:myex="http://id.mycompany.com/presence/"
entity="pres:someone@example.com"> entity="pres:someone@example.com">
<impp:tuple id="t6j2ds"> <impp:tuple id="tj25ds">
<impp:status> <impp:status>
<impp:basic>open</impp:basic> <impp:basic>open</impp:basic>
</impp:status> </impp:status>
<myex:complexExtension> <myex:complexExtension>
<myex:ex1 impp:mustUnderstand="1">val1</myex:ex1> <myex:ex1 impp:mustUnderstand="1">val1</myex:ex1>
<myex:ex2>val2</myex:ex2> <myex:ex2>val2</myex:ex2>
</myex:complexExtension> </myex:complexExtension>
<impp:contact priority="0.725">tel:09012345678</impp:contact> <impp:contact priority="0.725">tel:+09012345678</impp:contact>
</impp:tuple> </impp:tuple>
<myex:mytag>My extended presentity information</myex:mytag> <myex:mytag>My extended presentity information</myex:mytag>
</impp:presence> </impp:presence>
Here, <myex:ex1> must be understood and, if it is not recognized, Here, <myex:ex1> must be understood and, if it is not recognized,
<myex:complexExtension> MUST be ignored. <myex:mytag> and <myex:complexExtension> MUST be ignored. <myex:mytag> and
<myex:ex2> MAY be ignored if they are not recognized. <myex:ex2> MAY be ignored if they are not recognized.
4.4. XML Schema Definitions 4.4. XML Schema Definitions
This section gives the XML Schema Definition [XMLSchema1] of the This section gives the XML Schema Definition [XMLSchema1] of the
"application/cpim-pidf+xml" format. This is presented as a formal "application/pidf+xml" format. This is presented as a formal
definition of the "application/cpim-pidf+xml" format. Note that the definition of the "application/pidf+xml" format. Note that the XML
XML Schema definition is not intended to be used with on-the-fly Schema definition is not intended to be used with on-the-fly
validation of the presence XML document. validation of the presence XML document.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:cpim-pidf" <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf"
xmlns:tns="urn:ietf:params:xml:ns:cpim-pidf" xmlns:tns="urn:ietf:params:xml:ns:pidf"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang--> <!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="presence" type="tns:presence"/> <xs:element name="presence" type="tns:presence"/>
skipping to change at page 20, line 4 skipping to change at page 19, line 48
This attribute may be used on any element within an optional This attribute may be used on any element within an optional
PIDF extension to indicate that the corresponding element must PIDF extension to indicate that the corresponding element must
be understood by the PIDF processor if the enclosing optional be understood by the PIDF processor if the enclosing optional
element is to be handled. element is to be handled.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
</xs:attribute> </xs:attribute>
</xs:schema> </xs:schema>
5. IANA Considerations 5. IANA Considerations
This memo calls for IANA to: This memo calls for IANA to:
- register a new MIME content-type application/cpim-pidf+xml, - register a new MIME content-type application/pidf+xml,
per [RFC 2048], per [RFC 2048],
- register a new XML namespace URN per [XML-Registry]. - register a new XML namespace URN per [XML-Registry].
- register a new XML namespace URN for status extensions per - register a new XML namespace URN for status extensions per
[XML-Registry]. [XML-Registry].
The registration templates for these are below. For more information The registration templates for these are below. For more information
on status extensions, see section 4.2.5. on status extensions, see section 4.2.5.
5.1. Content-type registration for 'application/cpim-pidf+xml' 5.1. Content-type registration for 'application/pidf+xml'
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/cpim-pidf+xml Subject: Registration of MIME media type application/pidf+xml
MIME media type name: application MIME media type name: application
MIME subtype name: cpim-pidf+xml MIME subtype name: pidf+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is UTF-8. Indicates the character encoding of enclosed XML. Default is
UTF-8.
Encoding considerations: Encoding considerations:
Uses XML, which can employ 8-bit characters, depending on the Uses XML, which can employ 8-bit characters, depending on the
character encoding used. character encoding used.
See RFC 3023 [RFC 3023], section 3.2. See RFC 3023 [RFC 3023], section 3.2.
Security considerations: Security considerations:
This content type is designed to carry presence data, which may This content type is designed to carry presence data, which may
be considered private information. Appropriate precautions should be considered private information. Appropriate precautions should
be adopted to limit disclosure of this information. be adopted to limit disclosure of this information.
Interoperability considerations: Interoperability considerations:
This content type provides a common format for exchange of presence This content type provides a common format for exchange of
information across different CPIM compliant protocols. presence information across different CPP compliant protocols.
Published specification: Published specification:
RFCXXXX (this document) RFCXXXX (this document)
Applications which use this media type: Applications which use this media type:
Presence and instant messaging systems. Presence and instant messaging systems.
Additional information: Additional information:
Magic number(s): Magic number(s):
skipping to change at page 21, line 4 skipping to change at page 20, line 50
Published specification: Published specification:
RFCXXXX (this document) RFCXXXX (this document)
Applications which use this media type: Applications which use this media type:
Presence and instant messaging systems. Presence and instant messaging systems.
Additional information: Additional information:
Magic number(s): Magic number(s):
File extension(s): File extension(s):
Macintosh File Type Code(s): Macintosh File Type Code(s):
Person & email address to contact for further information: Person & email address to contact for further information:
Hiroyasu Sugano Hiroyasu Sugano
E-mail: sugano.h@jp.fujitsu.com E-mail: sugano.h@jp.fujitsu.com
Intended usage: Intended usage:
LIMITED USE LIMITED USE
Author/Change controller: Author/Change controller:
This specification is a work item of the IETF IMPP working group, This specification is a work item of the IETF IMPP working group,
with mailing list address <impp@iastate.edu>. with mailing list address <impp@iastate.edu>.
Other information: Other information:
This media type is a specialization of application/xml [RFC 3023], This media type is a specialization of application/xml [RFC 3023],
and many of the considerations described there also apply to and many of the considerations described there also apply to
application/cpim-pidf+xml. application/pidf+xml.
5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim- 5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf'
pidf'
URI URI
urn:ietf:params:xml:ns:cpim-pidf urn:ietf:params:xml:ns:pidf
Description: Description:
This is the XML namespace URI for XML elements defined by [RFCXXXX] This is the XML namespace URI for XML elements defined by
to describe CPIM presence information in application/cpim-pidf+xml [RFCXXXX] to describe CPP presence information in
content type. application/pidf+xml content type.
Registrant Contact Registrant Contact
IETF, IMPP working group, <impp@iastate.edu> IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com> Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
XML XML
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=utf-8"/> content="text/html;charset=utf-8"/>
<title>Namespace for CPIM presence information</title> <title>Namespace for CPP presence information</title>
</head> </head>
<body> <body>
<h1>Namespace for CPIM presence information</h1> <h1>Namespace for CPP presence information</h1>
<h2>application/cpim-pidf+xml</h2> <h2>application/pidf+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
5.3. URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim- 5.3. URN sub-namespace registration for
pidf:status' 'urn:ietf:params:xml:ns:pidf:status'
URI URI
urn:ietf:params:xml:ns:cpim-pidf:status urn:ietf:params:xml:ns:pidf:status
Description: Description:
This is the XML namespace URI for XML elements defined by [RFCXXXX] This is the XML namespace URI for XML elements defined by
to describe extensions to the status of CPIM presence information [RFCXXXX] to describe extensions to the status of CPP presence
in application/cpim-pidf+xml content type. information in application/pidf+xml content type.
Registrant Contact Registrant Contact
IETF, IMPP working group, <impp@iastate.edu> IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com> Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
XML XML
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=utf-8"/> content="text/html;charset=utf-8"/>
<title>Namespace for CPIM status extensions</title> <title>Namespace for CPP status extensions</title>
</head> </head>
<body> <body>
<h1>Namespace for CPIM presence information extensions</h1> <h1>Namespace for CPP presence information extensions</h1>
<h2>application/cpim-pidf+xml</h2> <h2>application/pidf+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
6. Security Considerations 6. Security Considerations
Because presence is very privacy-sensitive information, the protocol Because presence is very privacy-sensitive information, the protocol
for the presence information MUST have capabilities to protect PIDF for the presence information MUST have capabilities to protect PIDF
from possible threats, such as eavesdropping, corruption, tamper and from possible threats, such as eavesdropping, corruption, tamper and
replay attacks. These security mechanisms must be able to be used replay attacks. These security mechanisms must be able to be used
end-to-end between presentities and watchers, even if the watcher and end-to-end between presentities and watchers, even if the watcher and
the presentity employ different presence protocols and communicate the presentity employ different presence protocols and communicate
through a CPIM gateway. Since the 'application/cpim-pidf+xml' MIME through a CPP gateway. Since the 'application/pidf+xml' MIME type is
type is defined for this PIDF document, staging security for PIDF at defined for this PIDF document, staging security for PIDF at the MIME
the MIME level (with S/MIME [RFC2633]) seems appropriate. Therefore, level (with S/MIME [RFC2633]) seems appropriate. Therefore, PIDF
PIDF should follow the normaivge recommendations for the use of should follow the normative recommendations for the use of S/MIME
S/MIME (including minimum ciphersuites) given in the core CPIM (including minimum ciphersuites) given in the core CPP specification.
specification.
Note that the use of timestamps in PIDF (see section 4.1.7) can Note that the use of timestamps in PIDF (see section 4.1.7) can
provide some rudimentary protection against replay attacks. If a provide some rudimentary protection against replay attacks. If a
watcher receives presence information that is outdated, it SHOULD be watcher receives presence information that is outdated, it SHOULD be
ignored. A watcher can determine that presence information is ignored. A watcher can determine that presence information is
outdated in a number of fashions. Most significantly, if the newest outdated in a number of fashions. Most significantly, if the newest
timestamp in presence information is older than the newest timestamp timestamp in presence information is older than the newest timestamp
in the last received presence information, it should be considered in the last received presence information, it should be considered
outdated. Applications and protocols also are advised to adopt their outdated. Applications and protocols also are advised to adopt their
own rules for determining how frequently presence information should own rules for determining how frequently presence information should
skipping to change at page 23, line 35 skipping to change at page 23, line 32
time to reach a watcher, and if a presentity has not refreshed its time to reach a watcher, and if a presentity has not refreshed its
presence state in the last hour, it is probably offline). presence state in the last hour, it is probably offline).
7. Internationalization Considerations 7. Internationalization Considerations
All the processors conformant to this specification MUST be able to All the processors conformant to this specification MUST be able to
generate and accept UTF-8 encoding, this being one of the mandatory generate and accept UTF-8 encoding, this being one of the mandatory
character encodings for XML conforming processors, and also required character encodings for XML conforming processors, and also required
by the policies set out in RFC 2277 [RFC2277]. by the policies set out in RFC 2277 [RFC2277].
Other character encodings MAY be accepted (but CPIM compliant Other character encodings MAY be accepted (but CPP compliant
processors are strongly discouraged from emitting anything other than processors are strongly discouraged from emitting anything other than
UTF-8). UTF-8).
8. Normative References 8. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[RFC2779] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
[XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, [XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", "Extensible Markup Language (XML) 1.0 (Second Edition)",
W3C Recommendation, October 2000, W3C Recommendation, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006> <http://www.w3.org/TR/2000/REC-xml-20001006>
[MIME] Multipurpose Internet Mail Extensions. See RFC 822, RFC 2045, [MIME] Multipurpose Internet Mail Extensions. See RFC 2045,
RFC 2046, RFC 2047, RFC 2048, and RFC 2049. RFC 2046, RFC 2047, RFC 2048, and RFC 2049.
[RFC1766] H. Alvestrand, "Tags for the Identification of Languages", [RFC3066] H. Alvestrand, "Tags for the Identification of Languages",
RFC 1766, March 1995. RFC 3066, March 1995.
[RFC3339] G. Klyne and C.Newman, "Date and Time on the Internet: [RFC3339] G. Klyne and C.Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002. Timestamps", RFC 3339, July 2002.
[XML-NS] Tim Bray, Dave Hollander, and Andrew Layman "Namespaces in [XML-NS] Tim Bray, Dave Hollander, and Andrew Layman "Namespaces in
XML", W3C recommendation: xml-names, 14 January 1999, XML", W3C recommendation: xml-names, 14 January 1999,
<http://www.w3.org/TR/REC-xml-names> <http://www.w3.org/TR/REC-xml-names>
[URI] T. Berners-Lee, R.T.Fielding and L. Masinter, "Uniform [URI] T. Berners-Lee, R.T.Fielding and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URN] R. Moats, "URN Syntax", RFC 2141, May 1997. [URN] R. Moats, "URN Syntax", RFC 2141, May 1997.
[URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", RFC [URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", RFC
2648, August 1999. 2648, August 1999.
[XML-Registry] M. Mealling, "The IETF XML Registry", [XML-Registry] M. Mealling, "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-03, Work in Progress. draft-mealling-iana-xmlns-registry-04, Work in Progress.
[RFC2277] H. Alvestrand, "IETF Policy on Character Sets and [RFC2277] H. Alvestrand, "IETF Policy on Character Sets and
Languages", RFC 2277, BCP 18, January 1998. Languages", RFC 2277, BCP 18, January 1998.
[XMLSchema1] H. Thompson, D. Beech, M. Maloney and N. Mendelsohn, [XMLSchema1] H. Thompson, D. Beech, M. Maloney and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
<http://www.w3.org/TR/xmlschema-1/>. <http://www.w3.org/TR/xmlschema-1/>.
9. Informative References 9. Informative References
[CPIM] D. Crocker et al., "Common Presence and Instant Messaging [RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and
(CPIM)", draft-ietf-impp-cpim-02.txt, Work in Progress. Instant Messaging", RFC 2778, February 2000.
[RFC2779] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[CPIM] D. Crocker and J. Peterson, "Common Profile for Instant
Messaging (CPIM)", draft-ietf-impp-im-02.txt, Work in Progress.
[CPP] D. Crocker and J. Peterson, "Common Presence for Presence
(CPP)", draft-ietf-impp-pres-02.txt, Work in Progress.
[CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant [CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant
Messaging Message Format", draft-ietf-impp-cpim-msgfmt-06.txt, Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08.txt,
Work in Progress. Work in Progress.
[vCard] F. Dawson and T. Howes, "vCard MIME Directory Profile", [vCard] F. Dawson and T. Howes, "vCard MIME Directory Profile",
RFC 2426, September 1998. RFC 2426, September 1998.
[RFC2633] B. Ramsdell, "S/MIME Version 3 Message Specification", [RFC2633] B. Ramsdell, "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
[RFC3282] H. Alvestrand, "Content Language Headers", RFC 3282, [RFC3282] H. Alvestrand, "Content Language Headers", RFC 3282,
May 2002. May 2002.
skipping to change at page 25, line 33 skipping to change at page 25, line 33
Shingo Fujimoto Shingo Fujimoto
Fujitsu Laboratories Ltd. Fujitsu Laboratories Ltd.
64, Nishiwaki 64, Nishiwaki
Ohkubo-cho Ohkubo-cho
Akashi 674-8555 Akashi 674-8555
Japan Japan
E-mail: shingo_fujimoto@jp.fujitsu.com E-mail: shingo_fujimoto@jp.fujitsu.com
Graham Klyne Graham Klyne
Clearswift Corporation Nine by Nine
1310 Waterside, E-mail: GK@ninebynine.org
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Telephone: +44 11 8903 8903
Facsimile: +44 11 8903 9000
E-mail: graham.klyne@clearswift.com
Adrian Bateman Adrian Bateman
VisionTech Limited VisionTech Limited
Colton, Staffordshire, WS15 3LD Colton, Staffordshire, WS15 3LD
United Kingdom United Kingdom
E-mail: bateman@acm.org E-mail: bateman@acm.org
Wayne Carr Wayne Carr
Intel Corporation Intel Corporation
2111 NE 25th Avenue 2111 NE 25th Avenue
skipping to change at page 26, line 19 skipping to change at page 26, line 12
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St 1800 Sutter St
Suite 570 Suite 570
Concord, CA 94520 Concord, CA 94520
USA USA
Phone: +1 925/363-8720 Phone: +1 925/363-8720
E-mail: jon.peterson@neustar.biz E-mail: jon.peterson@neustar.biz
11. Appendix A. Document Type Definitions 11. Appendix A. Document Type Definitions
The Document Type Definition for the "application/cpim-pidf+xml" The Document Type Definition for the "application/pidf+xml" format is
format is described. The DTD here is presented only for described. The DTD here is presented only for informational for
informational for those who may not familiar with the XML Schema those who may not familiar with the XML Schema definition.
definition.
Note: the DTD does not show where extension elements can be added. Note: the DTD does not show where extension elements can be added.
See the XML Schema for that information. See the XML Schema for that information.
<!ENTITY % URL "CDATA"> <!ENTITY % URL "CDATA">
<!ENTITY % URI "CDATA"> <!ENTITY % URI "CDATA">
<!ENTITY % TUPLEID "CDATA"> <!ENTITY % TUPLEID "CDATA">
<!ENTITY % DATETIME "CDATA"> <!ENTITY % DATETIME "CDATA">
<!ENTITY % VALUETYPE "CDATA"> <!ENTITY % VALUETYPE "CDATA">
<!ENTITY % PRIORITY "CDATA"> <!ENTITY % PRIORITY "CDATA">
skipping to change at page 27, line 14 skipping to change at page 27, line 7
<!ATTLIST contact <!ATTLIST contact
priority %PRIORITY; #IMPLIED priority %PRIORITY; #IMPLIED
> >
<!ELEMENT note %NOTE;> <!ELEMENT note %NOTE;>
<!ELEMENT timestamp %DATETIME;> <!ELEMENT timestamp %DATETIME;>
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 114 change blocks. 
264 lines changed or deleted 257 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/