IETF IMPP Working Group Hiroyasu Sugano INTERNET-DRAFT Fujitsu Expires: July 7, 2000 Christophe Vermeulen Alcatel Presence Information Data Format for IMPP 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. This document and related documents are discussed on the impp mailing list. To join the list, send mail to impp-request@iastate.edu. To contribute to the discussion, send mail to impp@iastate.edu. The archives are at http://lists.fsck.com/cgi-bin/wilma/pip. The IMPP working group charter, including the current list of group documents, can be found at http://www.ietf.org/html.charters/impp-charter.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document is the first output from the PIDF team working to define Presence Information Data Format, the format for conveying PRESENCE INFORMATION on the transport protocol of IMPP. It describes the current status of discussion on the IMPP mailing list in relation to the scope of PIDF and the PIDF concrete format. The discussion is on-going at present and a future version of this series of Internet-Draft will eventually specify a concrete format of PIDF in conformance with the PITP (Presence Information Transport Protocol) specification and the IMPP Requirements [Reqts]. 1. Introduction Presence and Instant Messaging services have accepted broad attention as a new way of communication on the Internet. While there are a couple of services widely used in this area at present, each of those is based on its proprietary protocol. The Instant Messaging and Presence Protocol (IMPP) Working Group has been chartered to produce an Internet Standard to acquire interoperability for Presence and Instant Messaging services. This document is the first output from the PIDF team working to define Presence Information Data Format, the format for conveying PRESENCE INFORMATION on the transport protocol of IMPP. It describes the current status of discussion on the IMPP mailing list in relation to the scope of PIDF and the PIDF concrete format. The discussion is on-going at present and a future version of this series of Internet-Draft will eventually specify a concrete format of PIDF in conformance with the PITP (Presence Information Transport Protocol) specification and the IMPP Requirements [Reqts]. In this document, some terms from the IMPP Model document [Model] and the Requirements document [Reqts] appear in upper case, e.g. PRESENCE SERVICEE. 2. Terminology It would be helpful to (re)define some terms for the purpose of the discussion in this draft, although some of those are already defined in [Model] and [Reqts]. PRESENCE INFORMATION: Information published by PRESENTITIES to WATCHERS. PRESENCE INFORMATION DATA FORMAT (PIDF): Data format for conveying PRESENCE INFORMATION on the wire protocol PITP. While PIDF is primarily intended to encode PRESENCE INFORMATION, the current draft does not exclude other data to be encoded in the future PIDF, e.g. WATCHER INFORMATION, ACCESS RULES, member lists, and others. (see section 4.2.) SELECTIVE SUBSCRIPTION: A way of SUBSCRIPTION which allows to subscribe to a part of PRESENCE INFORMATION provided by the targeted PRESENTITY. This can be controlled either by SUBSCRIBERS or ACCESS RULES for the PRESENCE INFORMATION. PRESENCE UPDATE: A piece of information which specifies the difference of the updated PRESENCE INFORMATION and the one before the update. INTEREST LIST: A list of the current PRESENTITIES subscribed by a single SUBSCRIBER. Same as the Forward List (FL) in the MSN Messenger Service 1.0 Protocol [MSN Messenger]. 3. Scope of PIDF 3.1. Primary Scope The PIDF document will eventually specify a concrete format for PRESENCE INFORMATION (PI). In order to achieve that, firstly we have to clarify what kind of information should be conveyed as PI. It has been agreed in the IMPP WG that PRESENCE SERVICE is not only for INSTANT MESSAGING, but also for a variety of communication services and others. Thus, as a preparation for defining the concrete format for PI, we should agree about what sorts of information is expected to be in PI. Moreover, We should give a set of decision points for defining PIDF. These would provide a part of requirements for PI. Based on the acquired list of requirements for PRESENCE INFORMATION, the base format for PI will be defined. At present, there are two options for this: XML [REC-XML] vs. vCard [VCARD]. We should investigate the pros and cons of both to select one of those based on the requirements. Although the current version of the PIDF document will not cover the final decision, basic materials on which the decision should be based would be provided. After the selection of the base format, the concrete syntax for PIDF will be defined. The syntax must define at least the syntax for IM, and must have a method for extensions needed for other communication means or services. If NOTIFICATIONS or updates for PRESENCE INFORMATION are allowed to be in the form of differences, the format for PRESENCE UPDATES must also be specified. 3.2. Secondary Scope While any consensus has not achieved, there are opinions that the scope of the PIDF should include the following information. Actually, these are not PRESENCE INFORMATION in the definition above (while WATCHER INFORMATION is still grey). But, these are pieces of data which should be transfered on the protocol. Note also that these are only used inside each domain. Thus, it would be unnecessary in the case that the IMPP WG do concentrate on inter- domain protocols. 3.2.1. WATCHER INFORMATION The Model document defines WATCHER INFORMATION and stated that it would be transferable in the same format as PRESENCE INFORMATION. Although the Requirement document does not refer to it as it is, there is a requirement 8.1.11 which states the PRINCIPAL can obtain SUBSCRIPTION information targeted to her/his PRESENCE INFORMATION. If PITP provide a way to transfer the SUBSCRIPTION information, a concrete format for it must be specified. It might be in the scope of PIDF. 3.2.2. INTEREST LIST The Model and Requirement documents do not refer to this. But, practically, it would be useful to transfer the INTEREST LIST information between a client and a server. In this case, a concrete format for it is required. 3.2.3. ACCESS RULE It is a controversial issue whether or not the format for ACCESS RULE should be in the scope of PIDF. First of all, there are no consensus on whether the ACCESS RULES itself is in the scope of standardization. Even if it is in the scope, ACCESS RULES are a kind of information published not for WATCHERS but for PRESENCE SERVICE. There seems to be a strong objection to deal with ACCESS RULE in PIDF. On the other hand, there is an argument on the mailing list that ACCESS RULE should be in PIDF because it would be preferable when different pieces of PRESENCE INFORMATION could have different ACCESS RULES. 4. PIDF Requirements This section describes points to be considered in defining PIDF including what should be in the contents of PI. These will provide the points for making a decision on the base format for PIDF. Additionaly, other controversial issues in relation to PIDF design will be mentioned. 4.1. Decision Points for PIDF 4.1.1. Premises It has been agreed in the IMPP WG that presence should at least be transportable as a [MIME] object, similar to the text/xml definition of [RFC2376], so that it shares the default UTF-8 character set as default. This also conforms to the consensus on using MIME-based security mechanism (e.g. S/MIME, PGP/MIME) for end-to-end security. The PIDF should not violate these premises. 4.1.2. Decision Points 4.1.2.1. Expressiveness The PIDF should be expressive enough to be able to contain information listed in section 4.2. 4.1.2.2. Conciseness The Requirement document has been revised recently to include additional description on its deployment in wireless and mobile IP infrastructure. The PIDF must be concise sufficiently usable for bandwidth-restrictive networks and CPU-restrictive devices. 4.1.2.3. Extensibility The IMPP protocol(s) are expected to be deployed in various range of Internet services in the future. The PIDF must be extensible so that it will meet the future possible requirements for such services. 4.1.2.4. Availability This is not a requirement. But, availability of the existing software to handle the information in PIDF is practically important. 4.1.2.5. Competence for Structured Data This is not a requirement, either. But, PRESENCE INFORMATION itself is structured, and there would be a need to encode structured data for future extension. It would be desirable if PIDF can deal with it. 4.2. Contents Considerations 4.2.1. Expectations Following the discussions on the IMPP mailing list, the following kinds of information can be listed as expected items to be included in PRESENCE INFORMATION. (a) COMMUNICATION ADDRESS and its availability STATUS for availability (OPEN/CLOSE) of various COMMUNICATION ADDRESSES; IM, Telephone, Cellular phone, Teleconferencing, IRC, and so on. It is sometimes desirable to be accompanied with the addressing information for the communication means. (b) Note Most of examples in the published proposals have this item. This is usually a free text, such as "I've finished my work.", "I'll be back until 15:00." This is useful as a means for non-invasive communication. (c) Capability and Preference It seems to be acquired a rough consensus that PRESENCE INFORMATION should be able to include information on capabilities of the terminals or applications installed, and/or preferences of the principals. They possibly depend on a particualr COMMUNICATION MEANS. E.g. Plugins, maximum characters, preferred language, and so forth. (d) Status of PRINCIPAL There is an opinion that PRESENCE INFORMATION should include a kind of status information of a PRINCIPAL himself. This information may change dynamically. E.g. users' activities, the current location, mental status, and so forth. Changes in one user's mental status sometimes trigger communication with the user. (e) Personal Information Comparatively static information not directly combined with network presence. It is typically considered as personal profiles, e.g. Realname, Birthday, Country, Time Zone, Postal Address, and so on. 4.2.2. Required Contents Some of the above can be combined into one part in the actual PIDF. We will specify the PIDF to be able to include at least the following three parts. 4.2.2.1. COMMUNICATION ADDRESS and STATUS The PIDF should be able to include COMMUNICATION ADDRESS and its STATUS indicating the availability of the COMMUNICATION MEANS (following the Model document [Model]). It seems to be acquired a rough consensus that a COMMUNICATION ADDRESS should be encoded in a form of URL. 4.2.2.2. Note The PIDF should be able to include text information in a free form. We call it a note. The free text could be either related to a particular communication means or not. This part can be used for non-invasive messages and other status information. In addition, it can include a formatted personal information. 4.2.2.3. Capability and Preference The PIDF should be able to include capability and preference information in relation to a particular communication means, or a pointer to such kind of information. 4.3. Issues 4.3.1. Dynamic and Static Information There has been discussion on whether or not dynamically changing information and comparatively static information should be treated separately. There is an argument that they should be handled differently because static data should not be sent every time dynamic data changed. This seems an important opinion in the case of wireless environment. On the other hand, there is an objection from an opinion that the difference is just one of timescale and the different handling will cause unnecessary complexity and overhead. It seems that any consensus has been achieved in the WG. 4.3.2. SELECTIVE SUBSCRIPTION Colin Benson proposed a way of SUBSCRIPTION which allows to subscribe to a part of PRESENCE INFORMATION. This seems to be an important feature in a practical service of IMPP. There is an argument that it will be desired by the WATCHER side to be able to ask NOTIFICATIONS for only interested part of PI, and that it will have particular importance from the PRESENTITY side in the sense of privacy. However, some participants expressed strong objection to it, stating that this feature will also cause much complexity. Currently, there have not been an agreement on this issue. 5. Base Format 5.1. Existing Contributions At present, there have been published several contributions for PIDF. 5.1.1. vCard vCard [VCARD] is an Internet Standard format for carrying personal contact information. John Stracke proposed the way to extend vCard format to handle Instant Messaging Address (IMADDR type) and STATUS information (STATUS type parameter) [Stracke]. The STATUS type parameter could be attached to existing types such as TEL and EMAIL. The extension also include new type parameters EXPIRES and LASTMOD. 5.1.1.1. Pros and Cons vCard is a simple and extensible format suitable for carrying contact information. It provides a concise format. It can be handled by existing software and it provides us with a ready-made data model for representing non-IM COMMUNICATIONS ADDRESSES. It seems also an advantage that they already have a extension registration procedure. The disadvantage of vCard is that the syntax is flat and seems unsuitable for structured data. 5.1.2. XML XML [REC-XML] is an emerging standard for exchanging structured data, and it can provide fully extensible format. Greg Hudson [Hudson] and Christophe Vermeulen [Vermeulen] published Internet-Draft proposing concrete presence formats based on XML. 5.1.2.1. Pros and Cons XML's congeniality with structured data would make it easier to include various kind of information. Further, if ACCESS RULES or WATCHER INFORMATION are encoded in XML, it is preferable to unify the base syntax. XML can also be handled by a number of existing tools. XML's extensibility is both an advantage and disadvantage. An apparant disadvantage is that the XML format tends to be lengthy. XML is complicated and it provides unnecessary machinery for PIDF such as entities, processing instructions, CDATA sections, and so forth. PIDF should be defined by specifying a reasonable subset of XML. 5.2. Consideration For expressiveness and extensibility, it seems that XML has more advantage than vCard. But, for conciseness, vCard is more preferable. The decision point would be which do we consider more significant for PIDF, conciseness and expressiveness. We need more discussion. In particular, discussion based on concrete examples would be helpful. However, it appears that the discussion on the mailing list might not reach a consensus easily. It would be better to make a decision by hum shortly. 6. Security Considerations Security issues mainly affect the design of PITP and, except that PRESENCE INFORMATION must be transported as MIME object, PIDF seems to have little relation with them. However, if we think of SELECTIVE SUBSCRIPTION, we would have to consider encryption and/or digital signature on a part of PRESENCE INFORMATION. This will bring up an issue of whether or not the encrypted or signed pieces should be combined to a single data structure and how to do that (Multipart/related?). This would affect the design of PIDF in how to combine the pieces of PRESENCE INFORMATION. 7. Internationalization Considerations Character set and encoding ("Charset" [RFC2277]) of PI sent in notification or publication messages must be specified either in PITP or in PIDF. If PRESENCE TUPLES in a single message are allowed to have different charsets, the charsets must be specified in PIDF. But, this is unlikely the case. It seems reasonable to specify the message charset as a parameter of a PITP message. 8. References [VCARD] F. Dawson, T. Howes, "vCard MIME Directory Profile", RFC 2426 Lotus Development Corporation; Netscape Communications, September 1998. [REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0." W3C Recommendation REC-xml-19980210, February 1998. [Model] M. Day, J. Rosenberg, H. Sagano. "A Model for Presence and Instant Messaging", work in progress, draft-ietf-impp-model-03.txt. [Reqts] M. Day, S. Aggarwal, G. Mohr, J. Vincent. "Instant Message / Presence Protocol Requirements", work in progress, draft-ietf-impp-reqts-04.txt. [Basis] M. Day, S. Aggarwal, G. Mohr, G. Hudson. "Proposed Design Decisions for IMPP", work in progress, draft-day-impp-basis-00.txt. [MSN Messenger] R. Movva, W. Lai. "MSN Messenger Service 1.0 Protocol", work in progress, draft-movva-msn-messenger-protocol-00.txt. [MIME] N. Freed et al., "Multipurpose Internet Mail Extensions (MIME) Part One" to "Five", RFC 2045-2049, Innosoft et al., November 1996. [RFC2376] E. Whitehead, M. Murata, "XML Media Types", RFC 2376, UC Irvine, Fuji Xerox Info. Systems, July 1998. [Hudson] G. Hudson, "Proposed Format For Presence Information", work in progress, draft-hudson-impp-presence-00.txt [Vermeulen] C. Vermeulen, "Presence Info Data Format (PIDF)", work in progress, draft-vermeulen-impp-pidf-00.txt [Stracke] J. Stracke, "vCard Extensions For Presence Information", work in progress, draft-stracke-impp-presence-vcard-02.txt [RFC2277] H. Alvestrand, "IETF Policy on Character Sets and Languages", RFC 2277, January 1998. 9. Authors' Addresses Hiroyasu Sugano Fujitsu Laboratories Ltd. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555 Japan suga@flab.fujitsu.co.jp Christophe Vermeulen Alcatel Research Center DS9/C0 F. Wellesplein, 1 B-2018 Antwerp Belgium