Network Working Group INTERNET-DRAFT H. Sugano S. Fujimoto Fujitsu Expires: February 2002 August 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 proposes a common presence format specification for discussion in the IMPP WG. It also contains a list of issues raised in the IMPP mailing list so far to accelerate the discussions. Sugano et al. [Page 1] INTERNET DRAFT CPIM Presence Format August 2001 1. Introduction The IMPP working group has been trying to build CPIM specifications to achieve interoperability of IM and Presence services between different protocol domains. In particular, The work on CPIM Message Format [CPIM-MSG] defines a common format for instant messages, which enables secure end-to-end IM exchange. For the presence service, although the group has agreed that there should be a common format for presence informantion, there has been very little discussion on the concrete format for that. This memo proposes a CPIM common presence format specification for discussion in the group. It also contains a list of issues raised in the IMPP mailing list so far to accelerate the discussions. 2. Assumptions and design decisions We took the starting point of our consideration from the minutes of the discussion in the IETF50 IMPP meeting. Thus, the payload content for (common) presence information should include: presentity URL list of contact URLs status (open,closed) timestamp human readable comment relative priority presentity human readable comment - independent of any contact Note that extensibility is required to the format and that it was also agreed in the IETF50 meeting that XML should be used for the payload format. Then, we took the following assumptions for the design. (a) A presence payload should be able to be transported securely from presentity to watchers. (b) A presence server may add some metadata and it may sign or encrypt the presence payload. (c) Presence tuples from different sources (presentities) may be transported in a single NOTIFY message. Based on these assumptions, we adopted our overall design decisions as follows: (1) A presence payload is in XML [XML]. This follows the agreement in the IETF50 meeting. Sugano et al. [Page 2] INTERNET DRAFT CPIM Presence Format August 2001 (2) A presence payload is accompanied with RFC822 style headers for metadata [RFC822]. (3) Multiple presence payloads can be enclosed using MIME multipart [MIME]. 3. Overall Presence Information Data Structure For an overall presence information data format, we propose to reuse "message/cpim" content type defined by the CPIM message format document [CPIM-MSG] and define some new headers for content-related metadata and an XML payload format for presence information. Note that this content can optionally be signed or encrypted using MIME security multiparts in conjunction with an appropriate security scheme. Thus, the complete presence information data looks like this: m: Content-type: message/cpim s: h: (message-metadata-headers) s: e: (encapsulated MIME entity containing presence payload) where, "m:", "s:", "h:", "e:" have the same meaning as defined in the CPIM-MSGFMT document and only used to indicate the different parts of the presence data. Message metadata used for presence information is a subset of those defined by the MSGFMT document. 3.1. Content Part The content part of this object, the e: part of the above schema, further contains presence payloads with the content headers. The content header part includes the Content-type header, whose value indicates whether it contains a single presence payload or multiple presence payloads. This memo defines a new content type "application/cpim-pidf+xml" for an XML-encoded presence payload. The Content-type header has the value application/cpim-pidf+xml when the content part contains a single presence payload. If the content part contains multiple presence payloads, the value of the Content-type header MUST be multipart/mixed. Each part of the multipart entity itself will be an application/cpim-pidf+xml type Sugano et al. [Page 3] INTERNET DRAFT CPIM Presence Format August 2001 object and each part contains content headers for its payload. It can optionally be a signed or encrypted MIME entity using the MIME security multiparts in conjunction with an appropriate security scheme. 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. General Design The format is designed to align with the agreement in the IMPP group so far described in the section 2. A single payload contains a list of presence tuples and other information related to the presentity. 4.2. XML Format Definitions An application/cpim-pidf+xml object is a well formed XML document. 4.2.1. The element The root element of the application/cpim-pidf+xml object is defined as . This element contains one or more elements and an optional element. The reason that the is optional is that it is sometimes needed to hide the timestamp of the presence information change. The element SHOULD contain an 'xmlns' attribute to indicate the namespace of this version of presence payloads. 4.2.2. 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. The element MUST contain a 'name' attribute which is used to distinguish this tuple from other tuples of the same presentity. The value of 'name' attribute MUST be unique in a single presentity. 4.2.3. The element Sugano et al. [Page 4] INTERNET DRAFT CPIM Presence Format August 2001 The element contains a mandatory element and an optional element. 4.2.4. The element The element contains a CDATA value, which is either "open" or "closed". The value "open" means the availability of the contact means in a general sense and "closed" means it is unavailable. 4.2.5. The element The element contains a CDATA value which describes the detailed status of the contact means. This element has a mandatory attribute 'type' and an optional attribute 'schema'. The 'type' attribute indicates the type of this tuple and the values of the element varies dependent on the type value. The optional its possible values, which is usually a DTD. 4.2.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. 4.2.7. The element The element contains a CDATA value, which is usually used for a human readable comment related to this tuple. 4.2.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 [?]. 4.3. Example open away im:shingo@jp.fujitsu.com Sugano et al. [Page 5] INTERNET DRAFT CPIM Presence Format August 2001 I'll be in Tokyo tomorrow open mailto:shingo@jp.fujitsu.com 4.4. DTD Data Type Definition of the application/cpim-pidf+xml format. Sugano et al. [Page 6] INTERNET DRAFT CPIM Presence Format August 2001 5. Header Definitions This section defines a set of headers which are used to convey the metadata. All the metadata, both message and content headers, are produced by the presence server. 5.1. Message Headers Among the headers defined by the CPIM message format document [CPIM- MSG], we use the following headers to convey the presence information. 5.1.1. The 'From' header The 'From' header contains the address (pres: URL) of the presentity. This header is mandatory. 5.1.2. The 'To' header The 'To' header contains the address (pres: URL) of the watcher. This header is optional. 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. 5.1.4. The 'NS' header The "NS" header is used to declare a local namespace prefix as defined by [CPIM-MSG]. 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]. 5.2. Content Headers 5.2.1. The 'Content-Type' header The 'Content-Type' header contains the type of the content. Sugano et al. [Page 7] INTERNET DRAFT CPIM Presence Format August 2001 5.2.2. 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.2.3. The 'Presence-Modified' header The 'Presence-Modified' header has no value. This header MAY be used only in the NOTIFICATION message if it contains the multipart presence payloads. The existence of this header indicates that this part has caused the notification. 6. Examples The following exapmle 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_fujimoto@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 Presence-Data-ID: part1 open away im:shingo@jp.fujitsu.com I'll be in Tokyo tomorrow Sugano et al. [Page 8] INTERNET DRAFT CPIM Presence Format August 2001 open mailto:shingo@jp.fujitsu.com --PRESENCE-BLOCKS Content-Type: application/cpim-pidf+xml Presence-Data-ID: part2 Presence-Modified: open tel:09012345678 open im:shingo@mobilecarrier.ne.jp --PRESENCE-BLOCKS-- 7. Security Considerations The proposed format for conveying presence information is so designed 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. Sugano et al. [Page 9] INTERNET DRAFT CPIM Presence Format August 2001 8. Discussions The authors understand that there are some issues in our proposal to be discussed and agreed on for the common presence format. Those could be listed as follows; (a) Should such server generated metadata as From, To, DateTime in this draft be defined as a part of common presence data format? This draft proposes to use several headers as server generated metadata as a part of common presence data format. This is because it would be necessary to convey these information to the end system (UA) as it is. It would also be desirable to allow server-side third party signing for such data. So, this may induce another relating question; is the third party signing on the presence service necessary? (b) If the answer to (a) is yes , the next issue is what is the best format for the metadata (message/cpim or any other?). We have adopted the message/cpim format because it can be reused with no difficulty to contain such metadata and it is RFC822 based. The reason to prefer an RFC822 based format is that it can nicely fit with MIME security framework which could be utilized when the user agents sign the presence data. (c) Extension framework In the earlier idea stage, we thought it preferable that local extensions could be confined within a special element (). There have been several objections to it which argue XML is naturally extensible and we have no need to such an element. We have agreed with their arguments and cut this element out. (d) XML format We need to agree on the details of the XML format itself. In fact, there has been proposed an idea to contain multiple contact elements in a single tuple element. Further discussions are needed. 9. References [CPIM] D. Crocker et al., "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-cpim-01.txt, Work in Progress. Sugano et al. [Page 10] INTERNET DRAFT CPIM Presence Format August 2001 [CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-03.txt, Work in Progress. [XML] Extensible Markup Language (XML) 1.0 (Second Edition). http://www.w3.org/TR/2000/REC-xml-20001006, A W3C recommendation, October 2000. [RFC822] D. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, STD 11, Aug 1982. [MIME] Multipurpose Internet Mail Extensions. See RFC 822, RFC 2045, RFC 2046, RFC 2047, RFC 2048, and RFC 2049. [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. [SMIME] P. Hoffman, Ed, "S/MIME Version 3 Message Specification", RFC2633, June 1999. [DateTime] G. Klyne and C.Newman, "Date and Time on the Internet: Timestamps", draft-ietf-impp-datetime-04.txt, Work in Progress. 10. Author's Addresses H. Sugano suga@flab.fujitsu.co.jp Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674 Japan S. Fujimoto shingo@flab.fujitsu.co.jp Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674 Japan 11. Full Copyright Statement Sugano et al. [Page 11] INTERNET DRAFT CPIM Presence Format August 2001 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 12]