Network Working Group H. Sugano INTERNET-DRAFT S. Fujimoto Fujitsu G. Klyne Baltimore Technologies A. Bateman VisionTech W. Carr Intel J. Peterson NeuStar Expires: June 2003 December 2002 Common Presence and Instant Messaging (CPIM) Presence Information Data Format Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Please send comments to the authors or to the impp@iastate.edu discussion list. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Sugano et al. [Page 1] INTERNET DRAFT CPIM Presence Format December 2002 Abstract This memo specifies the Common Presence and Instant Messaging (CPIM) Presence Information Data Format (PIDF) as a common presence data format for CPIM-compliant Instant Messaging and Presence protocols, and also defines a new media type "application/cpim-pidf+xml" to represent the XML MIME entity for PIDF. Sugano et al. [Page 2] INTERNET DRAFT CPIM Presence Format December 2002 Table of Content 1. Introduction ......................................... 4 1.1. Terminology and Conventions .......................... 4 2. Design Decisions ..................................... 5 2.1. Minimal Model ........................................ 5 2.2. Added Features ....................................... 6 2.3. XML Encoding Decision ................................ 6 3. Overview of Presence Information Data Format ......... 7 3.1. The 'application/cpim-pidf+xml' Content Type ......... 7 3.2. Presence Information Contents ........................ 7 4. XML-encoded Presence Data Format ..................... 7 4.1. XML Format Definitions ............................... 8 4.1.1. The element ............................... 8 4.1.2. The element .................................. 8 4.1.3. The element ................................. 9 4.1.4. The element .................................. 10 4.1.5. The element ................................ 10 4.1.6. The element ................................... 10 4.1.7. The element .............................. 11 4.2. Presence Information Extensibility ................... 11 4.2.1. XML Namespaces Background ............................ 11 4.2.2. XML Namespaces In Presence Information ............... 12 4.2.3. Handling Of Unrecognized Element Names ............... 13 4.2.4. Status Value Extensibility ........................... 14 4.2.5. Standardizing Status Extensions ...................... 15 4.3. Examples ............................................. 16 4.3.1. Default Namespace with Status Extensions ............. 16 4.3.2. Presence with Other Extension Elements ............... 16 4.3.3. Example Mandatory To Understand Elements ............. 17 4.4. XML Schema Definitions ............................... 17 5. IANA Considerations .................................. 19 5.1. Content-type registration for 'application/cpim-pidf+xml' .................. 20 5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim-pidf' ........... 21 5.3. URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim-pidf:status' .... 22 6. Security Considerations .............................. 22 7. Internationalization Considerations .................. 23 8. Normative References ................................. 23 9. Informative References ............................... 24 10. Authors' Addresses .................................. 25 11. Appendix A. Document Type Definitions ............... 26 12. Full Copyright Statement ............................ 27 Sugano et al. [Page 3] INTERNET DRAFT CPIM Presence Format December 2002 1. Introduction The Common Profile for Instant Messaging (CPIM) specifications define a set of common operations and various formats to achieve interoperability between different Instant Messaging and Presence protocols which meet RFC 2779 [RFC2779]. The CPIM core specification [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 (PIDF) as a common presence data format for CPIM-compliant presence protocols. The significance of the common presence format primarily resides in the fact that it alleviates the load of gatewaying of messages with presence data payloads. Without such a common presence 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 presence format and extensibility required by RFC 2779. It only defines a minimal set of presence status values defined by the IMPP Model document [RFC2778]. However, a presence application is able to define its own status values using the extensibility framework provided by this memo. Defining such extended status values is beyond the scope of this memo. Note also that this memo defines only the format for a presence data payload and the extensibility framework for it. How the presence data is transferred within a specific protocol frame would be defined separately in a protocol specification. 1.1. Terminology and Conventions This memo makes use of the vocabulary defined in the IMPP Model document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are used in the same meaning as defined therein. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Sugano et al. [Page 4] INTERNET DRAFT CPIM Presence Format December 2002 [[[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 We have adopted the IMPP Model and Requirements documents [RFC2778, RFC2779] as the starting point of our discussion. The two RFCs contains a number of statements about presence information, which can be regarded as a basic set of constraints for the format design. Also, we took the minimalist approach to the design based on them. Starting from the minimal model, only the features that are necessary to solve particular problems have been combined. 2.1. Minimal Model This specification is based on the minimal model extracted from the IMPP Model and Requirements documents. The model consists of the following items. Each of them is accompanied with the corresponding RFCs and their section numbers as its grounds, e.g. (RFC2778:Sec.2.4) refers to Section 2.4 of RFC 2778. (a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES, where a PRESENCE TUPLE consists of a STATUS, an optional COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. Note that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is understood more narrowly in this document to refer only to a URI. (RFC2778:Sec.3) (b) STATUS has at least the mutually-exclusive values OPEN and CLOSED, which have meaning for the acceptance of INSTANT MESSAGES, and may have meaning for other COMMUNICATION MEANS. There may be other values of STATUS that do not imply anything about INSTANT MESSAGE acceptance. These other values of STATUS may be combined with OPEN and CLOSED or they may be mutually- exclusive with those values. (RFC2778:Sec.3, RFC2779:Sec.4.4.1- 4.4.3) (c) STATUS may consist of single or multiple values. (RFC2778:Sec.2.4) (d) There must be a means of extending the common presence format to represent additional information not included in the common format. The extension and registration mechanisms must be defined for presence information schema, including new STATUS conditions and new forms for OTHER PRESENCE MARKUP. (RFC2779: Sec.3.1.4-3.1.5) Sugano et al. [Page 5] INTERNET DRAFT CPIM Presence Format December 2002 (e) The common presence format must include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported. (RFC2779:Sec.3.1.2) (f) The common presence format must allow the PRESENTITY to secure presence information sent to a WATCHER. The format must allow integrity, confidentiality and authentication properties to be applied to presence information. (RFC2779:Sec5.2.1, 5.2.4, 5.3.1, 5.3.3) 2.2. Added Features In addition to the minimal model described above, the format specified in this specification has the following features. (a) Relative priorities of contact addresses should be specifiable in order to allow the source of PRESENCE INFORMATION to tell the receiver (WATCHER USER AGENTS) its preference over multiple contact means. (b) The presence format should be able to contain the timestamp of the creation of the PRESENCE INFORMATION. The timestamp in the presence document lets the receiver know the time of the creation of the data even if the message containing it arrives late for some reason. It can also be used to detect a replay attack, independent of the underlying signature mechanism. Note that this mechanism does not assume any global time synchronization system for watchers and presentities (see Appendix A of RFC2779, 8.1.4 A7), but rather assumes that the minimum length of time that might pass before presence information is considered stale is long enough that minor variations among system clocks will not lead to misjudgments of the freshness of presence information." 2.3. XML Encoding Decision The CPIM Presence Information Data Format encodes presence information in XML (eXtensible Markup Language [XML]), which is rapidly gaining broad acceptance as a syntactic framework to encode structured data transferred over the Internet. Regarding the features of PRESENCE INFORMATION discussed above, such that it has a hierarchical structure and it should be fully extensible, XML is considered as the most desirable framework over other candidates such as vCard [RFC2426]. Sugano et al. [Page 6] INTERNET DRAFT CPIM Presence Format December 2002 3. Overview of Presence Information Data Format This section describes an overview of the presence data format defined in this memo. 3.1. The 'application/cpim-pidf+xml' Content Type This memo defines a new content type "application/cpim-pidf+xml" for an XML MIME entity that encodes presence information conformant to this specification. This specification follows the recommendations and conventions described in [RFC3023], including the naming convention of the type ('+xml' suffix) and the usage of the 'charset' parameter. Although it is defined as optional, use of the 'charset' parameter is STRONGLY RECOMMENDED. If the 'charset' parameter is not specified, conforming XML processors to [XML] MUST follow the requirements in section 4.3.3 of [XML]. 3.2. Presence Information Contents This subsection outlines the information in an "application/cpim- pidf+xml" document. A full definition of the PIDF content is in Section 4. o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY. o List of presence tuples - Status: OPEN/CLOSED for Instant Messaging or status for other communication means. - Communication address: communication means and contact address of this tuple. (optional) - Relative priority: numerical value specifying the priority of this communication address. (optional) - Timestamp: timestamp of the change of this tuple.(optional) - Human readable comment: free text memo about this tuple (optional) o PRESENTITY human readable comment: free text memo about the PRESENTITY (optional). 4. XML-encoded Presence Data Format This section defines an XML-encoded presence information data format (PIDF) for use with CPIM compliant systems. A presence payload in this format is expected to be produced by the PRESENTITY (the source of the PRESENCE INFORMATION) and transported to the WATCHERS by the presence servers or gateways without any interpretation or Sugano et al. [Page 7] INTERNET DRAFT CPIM Presence Format December 2002 modification. 4.1. XML Format Definitions A PIDF object is a well formed XML document. It MUST have the XML declaration and it SHOULD contain an encoding declaration in the XML declaration, e.g. "". If the charset parameter of the MIME content type declaration is present and it is different from the encoding declaration, the charset parameter takes precedence. Every application conformant to this specification MUST accept the UTF-8 character encoding to ensure the minimal interoperability. 4.1.1. The element The root element of the "application/cpim-pidf+xml" object is defined as . This element contains any number (including 0) of elements, followed by any number (including 0) of elements, followed by any number of OPTIONAL extension elements from other namespaces. The element MUST have an 'entity' attribute. The value of the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing this presence document. The element MUST contain a namespace declaration ('xmlns') to indicate the namespace on which the presence document is based. The presence document compliant to this specification MUST have the namespace 'urn:ietf:params:xml:ns:cpim-pidf:'. It MAY contain other namespace declarations for the extensions used in the presence XML document. 4.1.2. The element The element is used to carry a piece of PRESENCE INFORMATION defined as PRESENCE TUPLE in RFC2778. Thus, it contains one mandatory element, followed by any number of OPTIONAL extension elements from other namespaces, followed by one OPTIONAL elements, followed by any number of OPTIONAL elements, followed by one OPTIONAL elements. Tuples provide a way of segmenting presence information. Protocols or Sugano et al. [Page 8] INTERNET DRAFT CPIM Presence Format December 2002 applications may choose to segment the presence information associated with a presentity for any number of reasons - for example, because components of the full presence information for a presentity have come from distinct devices or different applications on the same device, or have been generated at different times. Tuples should be preferred over other manners of segmenting presence information such as creating multiple PIDF instances. The element MUST contain an 'id' attribute which is used to distinguish this tuple from other tuples in the same XML document. The value of an 'id' attribute MUST be unique within 'id' attribute values of other tuples in the same document. An 'id' value is used by applications processing the presence document to identify the corresponding tuple in the previously acquired PRESENCE INFORMATION of the same PRESENTITY. The value of the 'id' attribute SHOULD be treated as just a CDATA value (no semantics). The element is OPTIONAL because a PRESENTITY might need to hide its COMMUNICATION ADDRESS or there might be tuples not related to any COMMUNICATION MEANS. Tuples that contain a status element SHOULD contain a address. Tuples MAY contain conflicting presence status - one might provide a of OPEN, and another in the same PIDF could contain a of CLOSED, even if they both contain the same address. The manner in which segmented presence information is understood by the WATCHER USER AGENT is highly dependent on the capabilities of the WATCHER USER AGENT and the presence application in question. In the absence of any application-specific or protocol-specific understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey the following guidelines. WATCHER USER AGENTS should note which tuples in the PIDF have changed their state since the last notification by correlating the 'id' of each with those received in previous notifications and comparing both values and elements in the tuples, if any are present. 4.1.3. The element The element contains one OPTIONAL elements, followed by any number of OPTIONAL extension elements from other namespaces, under the restriction that at least one child element appears in the element. These children elements of contain status values of this tuple. By allowing multiple status values in a single element, different types of status values, e.g. reachability and location, can be represented by a . See Section 4.3 for an example with multiple status values. Sugano et al. [Page 9] INTERNET DRAFT CPIM Presence Format December 2002 This memo only defines the status value element. Other status values may be included using the standard extensibility framework (see Section 4.2.4). Applications encountering unrecognized elements within may ignore them, unless they carry a mustUnderstand="true" or mustUnderstand="1" attribute (see section 4.2.3). Note that, while the element MUST have at least one status value element, this status value may not be the element. 4.1.4. The element The element contains one of the following strings: "open" or "closed". The values "open" and "closed" has the same meaning as OPEN and CLOSED defined in RFC 2778 respectively, and stand for availability of receiving instant messages if the is for an instant messaging address. They also have meanings of general availability for other communication means. But, this memo does not specify them in detail. 4.1.5. The element The element contains a URL of the contact address. It optionally has a 'priority' attribute, whose value means a relative priority of this contact address over the others. The value of the attribute MUST be a decimal number between 0 and 1 inclusive with at most 3 digits after the decimal point. Higher values indicate higher priority. Examples of priority values are 0, 0.021, 0.5, 1.00. If the 'priority' attribute is omitted, applications MUST understand that the contact address has the lowest priority. If the 'priority' value is out of the range, applications just SHOULD ignore the value and process it as if the attribute was not present. It is RECOMMENDED that applications handles a contact with higher priority than another one so that the priority is recognizable by users. How to handle contacts with the same priority is up to implementations. 4.1.6. The element The element contains a string value, which is usually used for a human readable comment. A element MAY appear as a child element of or as a child element of the element. In the former case, the comment is about the PRESENTITY and, in the latter case, the comment is regarding the particular tuple. Sugano et al. [Page 10] INTERNET DRAFT CPIM Presence Format December 2002 Note that, wherever it appears, a element SHOULD NOT be used, and interpreted, as a non-interoperable substitute for status of its parent element. The element SHOULD have a special attribute 'xml:lang' to specify the language used in the contents of this element as defined in Section 2.12 of [XML]. The value of this attribute is the language indentifier as defined by [RFC1766]. It MAY be omitted when the language used is implied by the larger context such as the encoding information of the contents, such as an xml:lang attribute on an enclosing XML element, or a Content-language header [RFC3282] on an enclosing MIME wrapper. 4.1.7. The element The element contains a string indicating the date and time of the status change of this tuple. The value of this element MUST follow the IMPP datetime format [RFC3339]. Timestamps that contain 'T' or 'Z' MUST use the capitalized forms. As a security measure, the element SHOULD be included in all tuples unless the exact time of the status change cannot be determined. For security guidelines for watchers receiving presence information with timestamps, see the Security Considerations. 4.2. Presence Information Extensibility The presence information extensibility framework is based on XML namespaces [XML-NS]. RFC2779 requires that PIDF have a means of extending values beyond . These extensions MUST NOT modify how is to be understood, nor change the the structure or semantics of PIDF bodies 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 Sugano et al. [Page 11] INTERNET DRAFT CPIM Presence Format December 2002 part of the name, followed by a colon (":"); e.g. ... 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:cpim-pidf Thus, simple presence data might be thus: open Sugano et al. [Page 12] INTERNET DRAFT CPIM Presence Format December 2002 tel:09012345678 or, using a default XML namespace: open tel:09012345678 As is generally the case in XML, 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 use recognized names. Extensions to PIDF are informational in nature - they provide additional information beyond 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, which attribute name is associated with the CPIM presence namespace.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:cpim-pidf' namespace that MUST be recognized in CPIM presence data. Processors MUST handle these as described, Sugano et al. [Page 13] INTERNET DRAFT CPIM Presence Format December 2002 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 block containing an unrecognized element that has a mustUnderstand='true' (or '1') attribute, it should treat the entire element as unrecognized and not attempt to process it. Note that the mustUnderstand attribute MUST NOT be used in a way that might prevent a minimal implementation from understanding the basic PIDF information defined in this specification. To ensure this, the mustUnderstand attribute MUST NOT be used outside elements within optional, so that non-recognition of a mandatory extension results in no worse than ignoring the optional extension in which it is contained. 4.2.4. Status Value Extensibility This memo only defines the 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: open home im:someone@example.com Some new status values will 'extend' the value of the 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 recognise the new extension, the 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. Sugano et al. [Page 14] INTERNET DRAFT CPIM Presence Format December 2002 4.2.5. Standardizing Status Extensions Although the existing PIDF definition allows arbitrary elements to appear in the element, it may be sometimes desirable to standardize extension status elements and their semantics (the meanings of particular statuses, how their should be interpreted). The URN 'urn:ietf:params:xml:ns:cpim-pidf:status' has been defined as a namespace URI for extensions standardized by the IETF, and new values in this namespace must be defined by a standards-track RFC. The following example XML Schema defines an extension for presence information, which can have the values of 'home', 'office', or 'car'. If the 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:cpim-pidf:status', and each RFC defining an extension should register an extension name within that namespace with IANA. 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 Sugano et al. [Page 15] INTERNET DRAFT CPIM Presence Format December 2002 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 , 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 open busy home im:someone@mobilecarrier.net Don't Disturb Please! Ne derangez pas, s'il vous plait 2001-10-27T16:49:29Z open mailto:someone@example.com I'll be in Tokyo next week 4.3.2. Presence with Other Extension Elements Sugano et al. [Page 16] INTERNET DRAFT CPIM Presence Format December 2002 open Extended value in tuple tel:09012345678 open im:someone@mobilecarrier.net My extended presentity information 4.3.3. Example Mandatory To Understand Elements open val1 val2 tel:09012345678 My extended presentity information Here, must be understood and, if it is not recognized, MUST be ignored. and MAY be ignored if they are not recognized. 4.4. XML Schema Definitions This section gives the XML Schema Definition [XMLSchema1] of the Sugano et al. [Page 17] INTERNET DRAFT CPIM Presence Format December 2002 "application/cpim-pidf+xml" format. This is presented as a formal definition of the "application/cpim-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. Sugano et al. [Page 18] INTERNET DRAFT CPIM Presence Format December 2002 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. 5. IANA Considerations Sugano et al. [Page 19] INTERNET DRAFT CPIM Presence Format December 2002 This memo calls for IANA to: - register a new MIME content-type application/cpim-pidf+xml, per [RFC 2048], - 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/cpim-pidf+xml' To: ietf-types@iana.org Subject: Registration of MIME media type application/cpim-pidf+xml MIME media type name: application MIME subtype name: cpim-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 CPIM compliant protocols. Published specification: RFCXXXX (this document) Applications which use this media type: Presence and instant messaging systems. Additional information: Magic number(s): Sugano et al. [Page 20] INTERNET DRAFT CPIM Presence Format December 2002 File extension(s): Macintosh File Type Code(s): Person & email address to contact for further information: Hiroyasu Sugano E-mail: 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 . Other information: This media type is a specialization of application/xml [RFC 3023], and many of the considerations described there also apply to application/cpim-pidf+xml. 5.2. URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim- pidf' URI urn:ietf:params:xml:ns:cpim-pidf Description: This is the XML namespace URI for XML elements defined by [RFCXXXX] to describe CPIM presence information in application/cpim-pidf+xml content type. Registrant Contact IETF, IMPP working group, Hiroyasu Sugano, XML BEGIN Namespace for CPIM presence information

Namespace for CPIM presence information

Sugano et al. [Page 21] INTERNET DRAFT CPIM Presence Format December 2002

application/cpim-pidf+xml

See RFCXXXX.

END 5.3. URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim- pidf:status' URI urn:ietf:params:xml:ns:cpim-pidf:status Description: This is the XML namespace URI for XML elements defined by [RFCXXXX] to describe extensions to the status of CPIM presence information in application/cpim-pidf+xml content type. Registrant Contact IETF, IMPP working group, Hiroyasu Sugano, XML BEGIN Namespace for CPIM status extensions

Namespace for CPIM presence information extensions

application/cpim-pidf+xml

See RFCXXXX.

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 Sugano et al. [Page 22] INTERNET DRAFT CPIM Presence Format December 2002 end-to-end between presentities and watchers, even if the watcher and the presentity employ different presence protocols and communicate through a CPIM gateway. Since the 'application/cpim-pidf+xml' MIME type is defined for this PIDF document, staging security for PIDF at the MIME level (with S/MIME [RFC2633]) seems appropriate. Therefore, PIDF should follow the normaivge recommendations for the use of S/MIME (including minimum ciphersuites) given in the core CPIM 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 CPIM compliant processors are strongly discouraged from emitting anything other than UTF-8). 8. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 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. Sugano et al. [Page 23] INTERNET DRAFT CPIM Presence Format December 2002 [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", RFC 3023, January 2001. [XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000, [MIME] Multipurpose Internet Mail Extensions. See RFC 822, RFC 2045, RFC 2046, RFC 2047, RFC 2048, and RFC 2049. [RFC1766] H. Alvestrand, "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC3339] G. Klyne and C.Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [XML-NS] Tim Bray, Dave Hollander, and Andrew Layman "Namespaces in XML", W3C recommendation: xml-names, 14 January 1999, [URI] T. Berners-Lee, R.T.Fielding and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [URN] R. Moats, "URN Syntax", RFC 2141, May 1997. [URN-NS-IETF] R. Moats, "A URN Namespace for IETF Documents", RFC 2648, August 1999. [XML-Registry] M. Mealling, "The IETF XML Registry", draft-mealling-iana-xmlns-registry-03, Work in Progress. [RFC2277] H. Alvestrand, "IETF Policy on Character Sets and Languages", RFC 2277, BCP 18, January 1998. [XMLSchema1] H. Thompson, D. Beech, M. Maloney and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, . 9. Informative References [CPIM] D. Crocker et al., "Common Presence and Instant Messaging (CPIM)", draft-ietf-impp-cpim-02.txt, Work in Progress. [CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-06.txt, Work in Progress. Sugano et al. [Page 24] INTERNET DRAFT CPIM Presence Format December 2002 [vCard] F. Dawson and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998. [RFC2633] B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [RFC3282] H. Alvestrand, "Content Language Headers", RFC 3282, May 2002. 10. Authors' Addresses Hiroyasu Sugano Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan E-mail: sugano.h@jp.fujitsu.com Shingo Fujimoto Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan E-mail: shingo_fujimoto@jp.fujitsu.com Graham Klyne Clearswift Corporation 1310 Waterside, 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 VisionTech Limited Colton, Staffordshire, WS15 3LD United Kingdom E-mail: bateman@acm.org Wayne Carr Intel Corporation 2111 NE 25th Avenue Sugano et al. [Page 25] INTERNET DRAFT CPIM Presence Format December 2002 Hillsboro, OR 97124 USA E-mail: wayne.carr@intel.com Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA Phone: +1 925/363-8720 E-mail: jon.peterson@neustar.biz 11. Appendix A. Document Type Definitions The Document Type Definition for the "application/cpim-pidf+xml" format is described. The DTD here is presented only for informational for those who may not familiar with the XML Schema definition. Note: the DTD does not show where extension elements can be added. See the XML Schema for that information. Sugano et al. [Page 26] INTERNET DRAFT CPIM Presence Format December 2002 12. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Sugano et al. [Page 27]