IETF IMPP Working Group Hiroyasu Sugano INTERNET-DRAFT Fujitsu Expires: September 10, 2000 Christophe Vermeulen Alcatel Robert Osborne Microsoft March 10, 2000 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 output from the PIDF team working on the definition of the Presence Information Data Format for conveying PRESENCE INFORMATION between PRESENTITIES, PRESENCE SERVICE and WATCHERS on top of the PRESENCE INFORMATION TRANSPORT PROTOCOL of the Sugano,Vermeulen,Osborne [Page 1] INTERNET DRAFT PIDF/IMPP 10 March 2000 IMPP set of protocols. It describes the current status of discussion on the IMPP mailing list in relation to the scope of PIDF as well as its concrete format. The discussion is on-going at present and future versions of this Internet-Draft will further specify the concrete format of PIDF in conformance with the IMPP Requirements RFC. 1. Introduction Presence and Instant Messaging services have received 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 series of draft documents define Presence Information Data Format (PIDF), the format for conveying PRESENCE INFORMATION on top of the PRESENCE INFORMATION TRANSPORT PROTOCOL of the IMPP set of protocols [PITP-MITP]. The present document describes the current status of discussion on the mailing list and some design points based on a rough consensus in the mailing list and the PIDF design team. It also presents a proposal for a concrete format based on XML as a springboard for further discussion. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . Additionally, this document makes extensive use of terms in all capitals defined in [Model] and [Reqts], including PRESENTITY, PRESENCE SERVICE or ACCESS RULES. 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]. CAPABILITY/PREFERENCE: information with relation to a particular COMMUNICATION ADDRESS which represents either various capability of the terminal and application relevant to the COMMUNICATION ADDRESS, or a PRINCIPAL's preference related to it. Examples are maximum characters, plugins of the application, preferred language, and so forth. Sugano,Vermeulen,Osborne [Page 2] INTERNET DRAFT PIDF/IMPP 10 March 2000 INTEREST LIST: a list of the PRESENTITIES in which a single WATCHER is interested. It would be usually expected that the WATCHER would subscribe to the PRESENTITIES in the LIST when she/he can receive NOTIFICATIONS. Same as the Forward List (FL) in the MSN Messenger Service 1.0 Protocol [MSN Messenger]. NOTE: a text in a free format to be displayed on the WATCHER's terminal. PRESENCE INFORMATION: information generated by PRESENTITIES that contain COMMUNICATION ADDRESSES and STATUS, referring to a PRINCIPAL, and transmitted by the PRESENCE SERVICE towards 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 PIDF, e.g. by including WATCHER INFORMATION, ACCESS RULES, INTEREST LIST, and others. (see section 3.2.) PRESENCE UPDATE: a piece of information which specifies the difference of the updated PRESENCE INFORMATION and the one before the update. 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. 3. Scope of PIDF 3.1. Primary Scope The PIDF document specifies the way of expressing PRESENCE INFORMATION as a textual document, that can be conveyed as content of PITP messages. As such, it will define the syntax that must be followed, and the semantic of this syntax. It has been agreed in the IMPP WG that PRESENCE INFORMATION should not only cover INSTANT MESSAGING, but also for a variety of COMMUNICATION MEANS and other data including the status of the PRESENTITY. Firstly, we should give a set of points for basic design of PIDF, which includes what sort of PRESENCE INFORMATION should appear in the format. Based on the acquired list of design points, Sugano,Vermeulen,Osborne [Page 3] INTERNET DRAFT PIDF/IMPP 10 March 2000 the syntax and the semantics of the PIDF will be defined in this document. 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. Controversial Elements While no consensus has been 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 transferred on the PITP protocol. 3.2.1. WATCHER INFORMATION The Model document defines WATCHER INFORMATION (WI) and stated that it could be transferable in the same format as PRESENCE INFORMATION. Although the Requirement document does not refer to the WI, there is a requirement 8.1.11 which states the PRINCIPAL can obtain SUBSCRIPTION information targeted to her/his PRESENCE INFORMATION. While this document does not propose any format for WI, it is expected to contain the IDENTIFIER of each WATCHER and information related to each subscription specified by the transport protocols. This requires more discussion in the WG. 3.2.2. INTEREST LIST An INTEREST LIST is a list of the PRESENTITIES in which a single WATCHER is interested. The Model and Requirement documents do not refer to this. However, it would be practically useful to transfer the INTEREST LIST information between a client and a server. In this case, a concrete format for it is required. An example of an INTEREST LIST is shown in Section 5.3.2. 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, as at least some PRESENCE SERVERS will definitely not be able Sugano,Vermeulen,Osborne [Page 4] INTERNET DRAFT PIDF/IMPP 10 March 2000 to interpret PRESENCE INFORMATION and remove ACCESS RULES before forwarding it to the WATCHERS. On the other hand, there is an argument on the mailing list that ACCESS RULE should be in PIDF as conveying them along with their TARGET eliminates the need for using references, and allows a TUPLE granularity. There is another opinion that, even if ACCESS RULE should be handled separately from PRESENCE INFORMATION, the definition for ACCESS RULES is required in the IMPP standard in order to assure inter-domain interoperability, and PIDF should cover it. 4. Basic Design This section describes basic design points for PIDF which seem to have reached a rough consensus in the WG. 4.1. Requirements The Requirements documents [Reqts] specifies the following requirements which are relevant to PIDF. (6.1.1.) All ENTITIES MUST produce and consume at least a common base format for PRESENCE INFORMATION. (6.1.2.) The common presence format MUST include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported. (6.1.3.) The common presence format MUST include a means to encapsulate contact information for the PRESENTITY's PRINCIPAL (if applicable), such as email address, telephone number, postal address, or the like. (6.1.4.) There MUST be a means of extending the common presence format to represent additional information not included in the common format, without undermining or rendering invalid the fields of the common format. (6.1.5.) The working group must define the extension and registration mechanisms for presence information schema, including new STATUS conditions and new forms for OTHER PRESENCE MARKUP. (6.1.6.) The presence format SHOULD be based on IETF standards such as vCard [RFC 2426] if possible. (7.4.1.) The common presence format MUST define a minimum Sugano,Vermeulen,Osborne [Page 5] INTERNET DRAFT PIDF/IMPP 10 March 2000 standard presence schema suitable for INSTANT MESSAGE SERVICES. (7.4.2.) When used in a system supporting INSTANT MESSAGES, the common presence format MUST include a means to represent the STATUS conditions OPEN and CLOSED. (7.4.3.) The STATUS conditions OPEN and CLOSED may also be applied to messaging or communication modes other than INSTANT MESSAGE SERVICES. Based on these requirements, we have been discussing design issues for PIDF. The following subsections describe basic design points which we consider have reached a rough consensus in the WG or in the design team. 4.2. General Design 4.2.1. PRESENCE INFORMATION MUST be a text document which is a MIME object [MIME]. The MIME type for the presence document will be defined later. Rationale: 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. 4.2.2. PRESENCE INFORMATION MUST be composed of as a collection of PRESENCE TUPLES, where each PRESENCE TUPLE represents either a COMMUNICATION ADDRESS with its STATUS or a piece of information that is specific to the PRESENTITY itself (e.g. its GLOBAL STATUS or PRINCIPAL INFORMATION). Rationale: A PRESENCE TUPLE is defined in the Model document [Model]. It is an extensible unit of PRESENCE INFORMATION which contains STATUS, an optional COMMUNICATION ADDRESS, and an optional OTHER MARKUP. The notion of TUPLES seems to provide a feasible basic component for PIDF. It also seems to reach a consensus on it. 4.2.3. PRESENCE INFORMATION MUST be formatted in a reasonable subset of XML [REC-XML]. Rationale: Although we have the requirement 6.1.6, a majority on the Sugano,Vermeulen,Osborne [Page 6] INTERNET DRAFT PIDF/IMPP 10 March 2000 mailing list seems to consider that XML is more desirable in favor of its expressiveness and its broad acceptance on the Internet. As XML's expressiveness could be its disadvantage, it seems to be justifiable to adopt a subset of full XML dropping unnecessary machinery for PIDF such as entities, processing instructions, CDATA sections, and so forth. XML can also be handled by a number of existing tools. Note: There was extensive discussion about the adoption of the base format for PIDF: XML vs. vCard [RFC2426]. Some contributions has been published based on one of the two format [Hudson,Stracke,Vermeulen]. Each has its advantage and disadvantage. XML provides fully extensible format for structured data, but full XML is complicated and XML based data format tends to be verbose. On the other hand, vCard is a concise and extensible format suitable for carrying contact information, but it seems inappropriate for other kinds of information such as WATCHER INFORMATION or ACCESS RULES. The answers to the questions the PIDF team asked on the mailing list shows that XML seems to be acceptable as a base format on which PIDF would be defined. 4.3. Contents 4.3.1. PIDF MUST includes a means to represent COMMUNICATION ADDRESS and its STATUS which indicates the availability of the COMMUNICATION ADDRESS. When used with COMMUNICATION ADDRESSES, STATUS MUST have the mutually exclusive values OPEN and CLOSED. Rationale: This is a main target of the supposed IMPP services. Note: it seems to be acquired a rough consensus that a COMMUNICATION ADDRESS should be encoded in a form of URL. 4.3.2. PIDF MUST include a means to represent a STATUS for the PRESENTITY itself, such as busy/away/available/... . Rationale: Through the discussion on the mailing list, it seems that a rough consensus has been achieved on this issue. Note: The STATUS for the PRESENTITY and the STATUS for the COMMUNICATION ADDRESSES SHOULD be considered to be independent of each other in order to avoid unnecessary complexity. 4.3.3. PIDF SHOULD include a means to represent a NOTE, a text information in a free form to be displayed on the WATCHER's terminal, Sugano,Vermeulen,Osborne [Page 7] INTERNET DRAFT PIDF/IMPP 10 March 2000 such as "Meeting until 5:00 p.m." Rationale: There has been an agreement that it is practically beneficial to include a NOTE in PRESENCE INFORMATION. Note: The free text could be either related to a particular communication means or not. 4.3.4. PIDF SHOULD include a means to represent CAPABILITY and PREFERENCE information with relation to a particular communication means, or a pointer to acquire such information. Rationale: It seems that a rough consensus has been achieved that PRESENCE INFORMATION should be able to include information on capabilities of the terminals or applications installed, and/or preferences of the principals. They usually depend on a particular COMMUNICATION MEANS. 4.4. Discussions 4.4.1. Dynamic and Stable Information There has been discussion on whether or not dynamically changing information and comparatively stable information should be treated separately. There is an argument that they should be handled differently because stable data should not be sent every time dynamic data changed. This opinion seems to have significance 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 not been achieved in the WG. 4.4.2. SELECTIVE SUBSCRIPTION SELECTIVE SUBSCRIPTION which allows to subscribe to a part of PRESENCE INFORMATION has been proposed and discussed on the mailing list. There has been an argument that this feature is needed by WATCHERS when they would like to ask NOTIFICATION for the only interested part of the entire PRESENCE INFORMATION. From the PRESENTITY side, it has been argued that if would be desirable from the privacy viewpoint if SUBSCRIPTION could be controlled per COMMUNICATION ADDRESS. This seems to be an important feature in a Sugano,Vermeulen,Osborne [Page 8] INTERNET DRAFT PIDF/IMPP 10 March 2000 practical service of IMPP. However, some participants expressed strong objection to it. They argued that this feature would cause much unnecessary complexity. Currently, there has been no consensus on this issue. If SELECTIVE SUBSCRIPTION is to be allowed, a strict syntax and a set of semantics must be defined for it. 4.4.3. Preference for COMMUNICATION ADDRESSES There is a proposal for PIDF which uses the preference tag contained in the tags representing COMMUNICATION ADDRESSES [Hudson]. In the proposal, its value is an integer and it shows the relative preference of the PRESENTITY among the COMMUNICATION ADDRESSES. It seems that there has not been sufficient discussion on the need of the preference. Is it obvious that such preference is required in PIDF? Further discussion would be needed. 5. XML Format Definition This section proposes an XML based format for PIDF. We consider it as a springboard for further discussion. Section 5.4 describes some of the design issues that we noticed we should discuss more on the mailing list to elaborate the proposal and achieve some consensus. 5.1. Document level specification A presence document is a MIME object that contains presence information. Its tentative MIME type is text/pidf-xml. Rationale : compliant with the forthcoming version of RFC2376, "XML Media Types". Actually, given that PITP decided to build its own protocol, and not reuse HTTP, text/xml would work as well. The presence document MUST adhere to the [REC-XML] specification. However, it is recognized that instant messaging will have to be supported on very light-weight terminals, that may contain only a very simple parser. Therefore the additional restrictions apply : A presence document SHOULDN'T include any processor instructions, CDATA section or external references. Client implementations MAY discard them silently. Servers SHOULD reject presence information Sugano,Vermeulen,Osborne [Page 9] INTERNET DRAFT PIDF/IMPP 10 March 2000 that contains the string "]]>" in it, with an appropriate error message sent to the client or server originating it. The format of the error message is out of scope for this document. However, this doesn't apply for the DTD definition. A reference to the DTD MAY be present in the document. The presence XML language is defined as a DTD in the normative appendix. Although clients and servers are not required to validate the presence documents according to that DTD, the presence documents MUST be valid according to that DTD, i.e. validating them must reveal no error. 5.2. XML Tags and attributes definitions 5.2.1. The . This element MUST contains zero or more presence tuples, ACL rules or other identical elements, as defined in the following section. All elements inside the root element MUST be identical, with the exception of the Sugano,Vermeulen,Osborne [Page 12] INTERNET DRAFT PIDF/IMPP 10 March 2000 One day I'll be outta here
I will check my answering machine as soon as I'm released from Alcatraz
All faxes are screened by jailers, so don't put escape plans on them !
5.3.2. Buddy List The following example is a simple buddy list, or an INTEREST LIST, that could be used for PIDF discussions. I assume here that that list is owned by a PRINCIPAL with the IDENTIFIER "im:suga@fujitsu.co.jp". 5.4. Discussions 5.4.1. XML Tags vs attributes for Presence Information There have been discussions on which XML style should be used Sugano,Vermeulen,Osborne [Page 13] INTERNET DRAFT PIDF/IMPP 10 March 2000 predominately within the PIDF. One option is to use attributes as the main method of presenting Presence Information. The opinion is that this would allow for a much more concise XML document, and will be easier to control as an attribute has a finite, but extensible, list of values. The second option is to not use attributes, but to enclose the Presence Information within tags. It is proposed that this style would allow for more efficient XML parsers to be hand-coded. However no proof has been shown that this is the case. It is also proposed that this method would present a more flexible approach in the future. This issue requires further investigation before a decision can be made. 5.4.2. Single heading tag vs Multiple heading tags Within the PIDF team there has been discussions on what form the XML heading tag should take. This tag is used as the marker to note the type of information enclosed within the XML document. A decision on the required method is linked to the previous discussion - XML Tags vs attributes, for Presence Information. The first option (that presented within this document) is that the 'type' of information should be noted by an attribute within a single tag (e.g. ). It is proposed that this solution would allow for a more concise specification, due to the reuse of elements within the document. The second option is that a specific tag should be used to note that type of information (e.g. ). The opinion is that this would allow for the different types of information (Presence, Access Control List) to be developed independently. It is hoped that some reuse may be used between the different types of XML document. No consensus has been achieved on this issue. 5.4.3. PRESENTITY identifiers There has been some discussion on which form of identifiers should be adopted for PRESENTITIES in the context of Service. The points of contention seem to be which should be adopted pure email address and URI, and in the case of URI, which URI scheme would be chosen ("presence:", "im:", "impp:", or others). Sugano,Vermeulen,Osborne [Page 14] INTERNET DRAFT PIDF/IMPP 10 March 2000 Although the current proposal uses "im:" (see the example in 5.4.1, "href" attribute in the "impp" tag), we understand that there is no consensus about that. In particular, under the requirement of separability of presence service and IM service, identifiers for PRESENTITIES should be a different scheme from the IM scheme. Further discussion is required. 5.4.4. Date format There has been discussion on which format should be adopted for the date format: RFC1123 or a subset of ISO8601. While it seems that there was a rough consensus on the adoption of the iCalendar subset of ISO8601 ([RFC2445] Section 4.3.5), the authors are not still confident of it. Moreover, if MIME is supported by the IMPP protocols, the adoption of RFC1123 would be more reasonable because it is already used in MIME. 6. Security Considerations The security aspect of the IMPP standard is investigated by one of other design team to produce the security framework document [Security]. While the security architecture to be adopted would primarily affect the design of transport protocols [PITP-MITP], it may have large amount of influence upon the PIDF design from the aspects of access control, encryption, and digital signature. As stated in 3.2.3, there is no consensus on where ACCESS RULES or Access Control List (ACL) should be placed in the IMPP standard. However, it seems to be justifiable that the format for ACL should be defined in the scope of PIDF because it specifies data structure which is transported on the protocols as PRESENCE INFORMATION. In that case, the ACL format MUST be defined in conformance with the related activities [Security,PITP-MITP]. For encryption and digital signature, PIDF looks to have less strong relation with them except for the adoption of MIME to be conformant with the existing MIME-based security framework. However, if the security architecture adopts other framework such as [XMLDSIG] for digital signature, the PIDF design would be largely affected by it. Moreover, if SELECTIVE SUBSCRIPTION is to be considered, we would have to investigate per TUPLE encryption and/or digital signature. This would bring up an issue of whether or not and how the encrypted or signed pieces should be combined to a single data structure, and would also cause some conflict with the existing security framework. Sugano,Vermeulen,Osborne [Page 15] INTERNET DRAFT PIDF/IMPP 10 March 2000 7. Internationalization Considerations Character set and encoding ("Charset" [RFC2277]) of PRESENCE INFORMATION 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 [PITP-MITP] S. Aggarwal, C. Benson, J. Stracke, C. Vermeulen, "Transport Protocol for Presence Information/ Instant Messaging", work in progress, draft-ietf-impp-pitp-mitp-00.txt, December 1999. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [Model] M. Day, J. Rosenberg, H. Sagano. "A Model for Presence and Instant Messaging", RFC2778, February 2000. [Reqts] M. Day, S. Aggarwal, G. Mohr, J. Vincent. "Instant Message / Presence Protocol Requirements", RFC2779, February 2000. [MSN Messenger] R. Movva, W. Lai. "MSN Messenger Service 1.0 Protocol", work in progress, draft-movva-msn-messenger-protocol- 00.txt, August 1999. [RFC2426] F. Dawson, T. Howes, "vCard MIME Directory Profile", RFC2426, September 1998. [MIME] N. Freed et al., "Multipurpose Internet Mail Extensions (MIME) Part One" to "Five", RFC 2045-2049, November 1996. [RFC2376] E. Whitehead, M. Murata, "XML Media Types", RFC 2376, July 1998. [REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0." W3C Recommendation REC-xml-19980210, February 1998. [RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, Editors, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [Hudson] G. Hudson, "Proposed Format For Presence Information", work in progress, draft-hudson-impp-presence-01.txt, February 2000. Sugano,Vermeulen,Osborne [Page 16] INTERNET DRAFT PIDF/IMPP 10 March 2000 [Vermeulen] C. Vermeulen, "Presence Info Data Format (PIDF)", work in progress, draft-vermeulen-impp-pidf-00.txt, November 1999. [Stracke] J. Stracke, "vCard Extensions For Presence Information", work in progress, draft-stracke-impp-presence-vcard-02.txt, November 1999. [RFC2445] F. Dawson, D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. [Security] G. Klyne, "Security Framework for Instant Messaging and Presence Protocol", work in progress, draft-ietf-impp-security- framework-01.txt, March 2000. [XMLDSIG] D. Eastlake, J. Reagle, D. Solo, "XML-Signature Syntax and Processing", work in progress, draft-ietf-xmldsig-core-05.txt, February 2000. [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 Christophe.Vermeulen@alcatel.be Robert Osborne Microsoft Corporation One Microsoft Way, Redmond, WA 98052 USA roberto@microsoft.com Sugano,Vermeulen,Osborne [Page 17]