Network Working Group H. Sugano INTERNET-DRAFT S. Fujimoto Fujitsu G. Klyne Baltimore Technologies A. Bateman VisionTech Expires: April 2002 October 2001 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 (2001). All Rights Reserved. Abstract This memo specifies CPIM Presence Information Data Format (PIDF) as a common presence data format for CPIM-compliant IM/Presence protocols. Sugano et al. [Page 1] INTERNET DRAFT CPIM Presence Format October 2001 Table of Content 1. Introduction ......................................... 3 1.1. Terminology and Conventions .......................... 3 2. Design Decisions ..................................... 3 2.1. Minimal Model ........................................ 3 3. Overall Presence Information Data Structure .......... 4 3.1. The 'application/cpim-pidf+xml' Content Type ......... 5 3.2. Combining Multiple Presence Documents ................ 5 4. XML-encoded Presence Data Format ..................... 6 4.1. XML Format Definitions ............................... 6 4.1.1. The element ............................... 6 4.1.2. The element ............................. 6 4.1.3. The element .................................. 6 4.1.4. The element ................................. 7 4.1.5. The element .................................. 7 4.1.6. The element ................................ 7 4.1.7. The element ................................... 7 4.1.8. The element .............................. 8 4.2. Presence Information Extensibility ................... 8 4.2.1. XML Namespaces Background ............................ 8 4.2.2. XML Namespaces In Presence Information ............... 9 4.2.3. Handling Of Unrecognized Element Names ............... 9 4.3. Examples ............................................. 10 4.3.1. Default Namespace And No Extensions .................. 10 4.3.2. Example Presence Information Extensions .............. 11 4.3.3. Example Mandatory To Understand Extensions ........... 11 4.4. DTD .................................................. 12 5. Wrapping 'application/cpim-pidf+xml' Data ............ 13 5.1. When Used With 'message/cpim' ........................ 13 5.1.1. The 'From' header .................................... 13 5.1.2. The 'To' header ...................................... 13 5.1.3. The 'DateTime' header ................................ 13 5.1.4. The 'NS' header ...................................... 14 5.1.5. The 'Require' header ................................. 14 5.2. When Used With 'multipart/mixed' ..................... 14 5.2.1. The 'Presence-Data-ID' header ........................ 14 5.3. Examples ............................................. 14 6. Security Considerations .............................. 15 7. IANA Considerations .................................. 16 8. References ........................................... 16 9. Author's Addresses ................................... 17 10. Full Copyright Statement ............................ 18 Sugano et al. [Page 2] INTERNET DRAFT CPIM Presence Format October 2001 1. Introduction The IMPP working group has been working to develop the Common Profile for Instant Messaging (CPIM) specifications to achieve interoperability of IM and Presence services between different protocol domains. The the CPIM core document [CPIM] defines a set of common operations and their parameters to be supported by interworking IM/Presence protocols. The work on CPIM Message Format [CPIM-MSG] defines a common format for instant messages, which enables secure end-to-end IM exchange. This memo defines the CPIM Presence Information Data Format (PIDF) as a common presence data format for CPIM-compliant IM/Presence protocols. Encoded in the common format, presence data can be securely transferred across the boundary of different protocol domains by utilizing digital signature and/or encryption. 1.1. Terminology and Conventions This memos makes use of the vocabulary defined in the IMPP Model document [RFC2778]. Terms such as as CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, SUBSCRIPTION, and WATCHER 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 [34]. [[[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 some 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 were combined. 2.1. Minimal Model This specification is based on the following minimal model and requirements. Sugano et al. [Page 3] INTERNET DRAFT CPIM Presence Format October 2001 (a) A presence data unit contains one or more PRESENCE TUPLES, where a PRESENCE TUPLE consists of a STATUS, an optional COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. (RFC2778: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:3, RFC2779:4.4.1-3) (c) STATUS may consist of single or multiple values. (RFC2778: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: 3.1.4-5) (e) The common presence format MUST include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported. (RFC2779:3.1.2) (f) The common presence format must allow the source of the presence data (i.e. presentity) to utilize some security mechanism (e.g. digital signature or encryption) for the secure transportation of the data. (RFC2779:5.2.1,5.3.1,5.3.3) 3. Overall Presence Information Data Structure This memo defines a new content type and header fields for a MIME entity containing CPIM presence data. The CPIM presence format uses XML (eXtensible Markup Language, [XML]) as the syntactic framework for the presece data document because XML is an excellent framework to contain structured data such as presence information and inherently extensible. A new content type "application/cpim-pidf+xml" is defined for the XML-encoded presence documents. The XML-encoded presence document MAY be enclosed by a MIME entity of the content type "message/cpim", which is defined as the CPIM Message Format [CPIM-MSG]. One of the cases for which the "message/cpim" format is necessary is that the presence server gives the third party Sugano et al. [Page 4] INTERNET DRAFT CPIM Presence Format October 2001 signature to the presence document with some additional data. Note that the "application/cpim-pidf+xml" content itself can optionally be signed or encrypted by the source of this presence data using MIME security multiparts in conjunction with an appropriate security scheme. 3.1. The 'application/cpim-pidf+xml' Content Type The MIME body of the content type "application/cpim-pidf+xml" includes the following information. 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: numerial 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). [[[ There were discussions on the IMPP mailing list about timestamp, priority, and human readable comment. For the timestamp and priority, it seems that we have reached a consensus. But, for human readable comment, more discussions will be needed. ]]] The content type "application/cpim-pidf+xml" MAY have a "charset" parameter to indicate the character set and its encoding used in the body. If no "charset" is specified, the application MUST treat the body as "UTF-8" encoded. 3.2. Combining Multiple Presence Documents If a presence service needs to combine multiple presence documents in a single notification message, the MIME multipart entity is used. The reason for using MIME multipart comes from an architectural consideration such that each component presence document may come from different sources and it might be secured with a MIME security mechanism by the presence source. For the purpose of combining multiple presence documents, the Sugano et al. [Page 5] INTERNET DRAFT CPIM Presence Format October 2001 "multipart/mixed" content type MUST be used. Each part of the multipart entity itself SHOULD be an "application/cpim-pidf+xml" type MIME entity or a signed or encrypted MIME entity using the MIME security multiparts in conjunction with an appropriate security scheme. Each multipart SHOULD contain a Presence-Data-ID header field whose value is used by the watcher user agent to identify the corresnponding part of the entire presence data of the particular presentity. 4. XML-encoded Presence Data Format This section defines an XML-encoded presence data format of the content type application/cpim-pidf+xml for presence payloads. A presence payload of this type is expected to be produced by the presentity (the source of the presence information) and transported to the watchers by the presence servers or gateways without any interpretation or modification. 4.1. XML Format Definitions An application/cpim-pidf+xml object is a well formed XML document. 4.1.1. The element The root element of the 'application/cpim-pidf+xml' object is defined as . This element contains one element, one or more elements, and an optional element. The element SHOULD contain an 'xmlns' attribute to indicate the namespace of the version of the presence document. The presence document compliant to this specification MUST have the namespace 'urn:ietf:params:cpim-presence:'. 4.1.2. The element The element MUST have an 'id' attribute and has no content. The value of the 'id' attribute is the 'pres' URL of the publisher presentity of this presence information. 4.1.3. The element The element is used to carry a piece of presence information defined as PRESENCE TUPLE in RFC2778. Thus, it contains a mandatory element and optional , , and elements. Sugano et al. [Page 6] INTERNET DRAFT CPIM Presence Format October 2001 The element MUST contain an 'id' attribute which is used to distinguish this tuple from other tuples of the same presentity. The value of 'id' attribute MUST be unique in a single presentity. The element is optional so as to allow a presentity to show its status hiding its communication address or to allow tuples not related to any communication means. 4.1.4. The element The element contains one or more elements. It can have multiple status values at the same time. 4.1.5. The element The element contains a CDATA value and has optional 'type' and 'schema' attributes. The 'type' attribute indicates the type of this value which restrict the range of the values in which the content CDATA value varies. The 'schema' attribute is a URL pointing to the definition of the type and its possible values, which is usually a DTD. If the type attribute does not appear, the application MUST understand that the type is 'urn:ietf:params:cpim-presence:status- type:basic', i.e. the 'basic' type whose possible values are either "open" or "closed". As defined in RFC 2778, "open" and "closed" stand for availability of receiving insatnt 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. Also, this memo does not specify other value types such as 'urn:ietf:params:cpim-presence:status-type:im'. However, the 'urn:ietf:params:cpim-presence:status-type:im' type will be defined later in another specification document. 4.1.6. 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 an integer ranged from 0 to 255 and the smaller integer means the higher priority. If the 'priority' attribute is omitted, applications MUST understand that the contact address has the lowest priority. 4.1.7. The element Sugano et al. [Page 7] INTERNET DRAFT CPIM Presence Format October 2001 The element contains a CDATA value, which is usually used for a human readable comment. A element MAY appear as a child element of and as that 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. 4.1.8. The element The element contains a CDATA value which is 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 [DateTime]. 4.2. Presence Information Extensibility The presence information extensibility framework is based on XML namespaces [XML-NS]. 4.2.1. XML Namespaces Background All elements and some attributes are associated with a "namespace", which is in turn associated with a globally unique URI. Any developer can introduce their own element names, avoiding conflict by choosing an appropriate namespace URI. Within the presence data, element or attribute names are associated with a particular namespace by a namespace prefix, which is a leading part of the name, followed by a colon (":"); e.g. ... 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 Sugano et al. [Page 8] INTERNET DRAFT CPIM Presence Format October 2001 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 [URN-SUB-NS]: urn:ietf:params:cpim-presence: Thus, simple presence data might be thus: open tel:09012345678 or, using a default XML namespace: open tel:09012345678 4.2.3. Handling Of Unrecognized Element Names The default rule is that any element with an unrecognized name is ignored (i.e. having an unrecognized namespace URI, or an unrecognized local name within that namespace). This includes all of Sugano et al. [Page 9] INTERNET DRAFT CPIM Presence Format October 2001 the element content, even if it appears to use recognized names. It may be that some extensions must be understood in order for the presence information to be properly understood. In such cases, the element name is qualified with a mustUnderstand='YES' attribute, which attribute name is associated with the CPIM presence namespace. NOTE: a mustUnderstand='YES' 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='YES' attribute, if necessary. This specification defines elsewhere the elements within the 'urn:ietf:params:cpim-presence:' namespace that MUST be generated and/or recognized in CPIM presence data. Processors MUST handle these as described here, even if they do not carry a mustUnderstand attribute. If an agent receives presence information containing an unrecognized element with a mustUnderstand='YES' attribute, it should treat the entire presence information as unrecognized and not attempt to process it. 4.3. Examples 4.3.1. Default Namespace And No Extensions OPEN BUSY HOME im:shingo@mobilecarrier.ne.jp Don't Disturb Please! 2001-10-27T16:49:29Z OPEN Sugano et al. [Page 10] INTERNET DRAFT CPIM Presence Format October 2001 mailto:shingo@jp.fujitsu.com I'll be in Tokyo tomorrow 4.3.2. Example Presence Information Extensions My extended presentity information open Extended value in tuple tel:09012345678 open im:shingo@mobilecarrier.ne.jp 4.3.3. Example Mandatory To Understand Extensions My extended presentity information open val1 val2 tel:09012345678 Sugano et al. [Page 11] INTERNET DRAFT CPIM Presence Format October 2001 Here, , must be understood, but and may be ignored if they are not recognized. 4.4. DTD Data Type Definition of the application/cpim-pidf+xml format. Sugano et al. [Page 12] INTERNET DRAFT CPIM Presence Format October 2001 5. Wrapping 'application/cpim-pidf+xml' Data [[[ A part of this section may contain what has not yet agreed upon in the IMPP group. Futher discussions are needed. ]]] As stated in Section 3, an 'application/cpim-pidf+xml' document MAY be wrapped by a 'message/cpim' message [CPIM-MSG]. It MAY also be a part of a MIME multipart entity. This section specifies how the 'application/cpim-pidf+xml' document can be packed in another MIME entity. 5.1. When Used With 'message/cpim' In order to use the CPIM Message Format, headers needed for this usage must be defined [CPIM-MSG]. Among the headers defined by the CPIM message format document, the following headers MAY be used to convey the presence information. The default namespace and namespace prefix implicitly defined are same as defined in the 'message/cpim' specification document. 5.1.1. The 'From' header The 'From' header contains the address (pres: URL) of the presentity as the publisher of the contained presence information. Any application compliant to this specification MUST recognize the 'From' header. This use of 'From' may be considered redundant in the presence of element in the presence document. This header is needed when the presence server explicitly states the publisher regardless of the content of presence documents. 5.1.2. The 'To' header The 'To' header contains the address (pres: URL) of the watcher as the target of the NOTIFY message containing this presence document. Any application compliant to this specification MUST recognize the 'To' header. 5.1.3. The 'DateTime' header The 'DateTime' header contains a character string of the format defined as IMPP datetime format [DateTime]. This value indicates the date and time at which the content part is created. The 'DateTime' header MUST be present as a 'message/cpim' metadata header if the message contains an 'application/cpim-pidf+xml' object. It MUST also be recognized by any application compliant to this specification. Sugano et al. [Page 13] INTERNET DRAFT CPIM Presence Format October 2001 5.1.4. The 'NS' header The "NS" header is used to declare a local namespace prefix as defined by [CPIM-MSG]. Any application compliant to this specification MUST recognize the 'NS' header. 5.1.5. The 'Require' header The "Require" header is used to specify a header or feature that must be implemented by the receiver, as defined by [CPIM-MSG]. Any application compliant to this specification MUST recognize the 'Require' header. 5.2. When Used With 'multipart/mixed' When multiple presence documents are combined within a simple notification message, the 'multipart/mixed' content type MUST be used. Each multipart SHOULD contain a 'Presence-Data-ID' header defined as follows. 5.2.1. The 'Presence-Data-ID' header The 'Presence-Data-ID' header contains the label for the unit of update. This header will be used for indicating the part is replacement of the part which contained in previous NOTIFICATION with same 'Presence-Data-ID' value. 5.3. Examples The following example is the message/cpim object containing two presence payload. It is supposed that the first block is published by a PC and the second block is published by a mobile phone, and the second block has caused the notification message conveying this multipart content. Content-Type: message/cpim From: pres:shingo@jp.fujitsu.com To: pres:suga@flab.fujitsu.co.jp DateTime: 2001-06-01T08:35:44+09:00 Content-Type: multipart/mixed; boundary="PRESENCE-BLOCKS" --PRESENCE-BLOCKS Content-Type: application/cpim-pidf+xml Sugano et al. [Page 14] INTERNET DRAFT CPIM Presence Format October 2001 Presence-Data-ID: part1 OPEN AWAY im:shingo@jp.fujitsu.com Boss Meeting OPEN mailto:shingo@jp.fujitsu.com --PRESENCE-BLOCKS Content-Type: application/cpim-pidf+xml Presence-Data-ID: part2 OPEN tel:09012345678 OPEN HOME im:shingo@mobilecarrier.ne.jp --PRESENCE-BLOCKS-- 6. Security Considerations The proposed format for conveying presence information is so designed Sugano et al. [Page 15] INTERNET DRAFT CPIM Presence Format October 2001 that it could be adaptable in circumstances under various security requirements. As a typical case, a user publishing his/her presence information may want to sign the data to prevent from being corrupted or tampered. This will ensure the integrity of presence information in an end-to- end manner. This proposal enables it by allowing MIME multipart security framework, such as usage of the multipart/signed data type. Another possible scenario is that of third party signing. If the computing power of the terminal device of the publishing user is restricted, the server side signing would be sometimes desirable to enhance the level of security in distributing presence information. This enables to prevent from so-called "the man in the middle" attacks when the presence notifications are distributed through the proxies or gateways. 7. IANA Considerations [[[Will need a registration template per [URN-SUB-NS], for the URN sub-namespace 'urn:ietf:params:cpim-presence:']]] 8. References [CPIM] D. Crocker et al., "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-cpim-01.txt, Work in Progress. (Temporarily Expired) [CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-03.txt, Work in Progress. [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. [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. [DateTime] G. Klyne and C.Newman, "Date and Time on the Internet: Sugano et al. [Page 16] INTERNET DRAFT CPIM Presence Format October 2001 Timestamps", draft-ietf-impp-datetime-04.txt, Work in Progress. [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. [URN-SUB-NS] M. Mealling, L. Masinter, T. Hardie and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", Internet-Draft draft-mealling-iana-urn-01, Work in Progress. 9. Author's Addresses Hiroyasu Sugano Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674 Japan E-mail: sugano.h@jp.fujitsu.com Shingo Fujimoto Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674 Japan E-mail: shingo_fujimoto@jp.fujitsu.com Graham Klyne Baltimore Technologies - Content Security Group, 1310 Waterside, Arlington Business Park Theale Reading, RG7 4SA United Kingdom. Telephone: +44 118 903 8000 Facsimile: +44 118 903 9000 E-mail: GK@ACM.ORG Sugano et al. [Page 17] INTERNET DRAFT CPIM Presence Format October 2001 Adrian Bateman VisionTech Limited Colton, Staffordshire, WS15 3LD United Kingdom E-mail: bateman@acm.org 10. Full Copyright Statement Copyright (C) The Internet Society (2001). 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 18]