Network working group G. Klyne, Content Technologies Ltd. Internet draft D. H. Crocker, Brandenburg Consulting M. T. Rose, Invisible Worlds, Inc. 18 October 2000 Expires: April 2001 Instant Messaging using IMXP Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract This document describes how to provision an instant text messaging and presence service using IMXP. Discussion of this document Please send comments to: . To subscribe: send a message with the body 'subscribe' to . Klyne, et al Internet draft [Page 1] Instant Messaging using IMXP 18 October 2000 Table of contents 1. Introduction.............................................3 1.1 Structure of this document ...........................3 1.2 Document terminology and conventions .................3 2. Background and goals.....................................3 2.1 Overview of IMXP .....................................4 2.2 INSTANT INBOX addressing .............................5 2.3 Identifying PRESENTITIES .............................5 2.4 WATCHER addressing ...................................5 2.5 PRESENCE SERVICE addressing ..........................5 2.6 IMXP access provisioning .............................6 2.7 Service goals ........................................6 3. Instant Message service..................................6 3.1 Format of Instant Messages ...........................7 3.2 Content of an instant message ........................11 3.3 Sending an instant message ...........................11 4. Presence service.........................................11 4.1 Format of presence information .......................11 4.2 Subscribing to receive presence information ..........11 4.3 Polling presence information .........................12 4.4 Publishing presence information ......................12 4.5 Watcher operations ...................................12 5. Internationalization considerations......................12 6. Security considerations..................................13 6.1 Security provisioning ................................13 7. Acknowledgements.........................................14 8. References...............................................14 9. Authors' addresses.......................................17 Appendix A: Amendment history...............................18 Full copyright statement....................................19 Klyne, et al Internet draft [Page 2] Instant Messaging using IMXP 18 October 2000 1. Introduction This document describes how to provision an instant text messaging and presence service using IMXP [4,5,6]. The service described here conforms to CPIM, the common interoperability framework for instant messaging [3]. 1.1 Structure of this document Section 2 provides background material, and sets out the goals of this service specification. Section 3 describes the IMXP-provisioned instant text messaging service in terms of the basic CPIM Message operation. Section 4 describes the IMXP-provisioned presence service in terms of basic CPIM Subscribe/Unsubscribe/Notify operations. 1.2 Document terminology and conventions Many special terms used in this document are described in RFC 2778 [2]. 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 RFC 2119 [7]. NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth. [[[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. Background and goals The requirements for an instant messaging and presence (IM/P) service are set out in RFC 2779 [1]. This sets out facilities for sending instant messages, real-time discovery information about the status of other parties on the network (presence), and discovering who is monitoring information about somebody's status (watchers). Klyne, et al Internet draft [Page 3] Instant Messaging using IMXP 18 October 2000 A framework for interoperability between different protocols satisfying these requirements is set out in CPIM [2]. The service described by this document is a provisioning of an instant text messaging and presence service using IMXP. 2.1 Overview of IMXP The basic philosophy of IMXP is: o The core mechanism is very simple: a range of services can be built using the basic core mechanisms provided. o Its design is based on familiar Internet mail architecture, leveraging a wealth of related experience. The IMXP relay mesh uses lightweight, near-real-time application datagram transfer nodes, analogous to email MTAs: o Relay processing is kept simple. Essential intelligence is kept at or near the network edge to enhance scalability; relays are not required to maintain state concerning message transfer. o Addressing and routing follow the classic email model. This uses hierarchical addresses (domain names) that can be understood by the entire relay mesh. o Hop-by-hop security framework. Authentication, privacy, and authorization rely on domains "keeping their own houses in order", in line with current Internet infrastructure. End-to-end security (OpenPGP or S/MIME) may be added to provide greater security. o Transport independence. A convergence layer (BEEP [8]) carries IMXP identically over variety of transports. o Other applications may use the same relay mesh. Asynchronous near-real-time message exchange with accessible, predictable behaviour is applicable to a numnber of loosely-coupled applications, or which instant text messaging is just one. Klyne, et al Internet draft [Page 4] Instant Messaging using IMXP 18 October 2000 2.2 INSTANT INBOX addressing CPIM defines an address format for instant messaging based on a URI containing a domain name and a local part. IMXP uses a message address with the same form as an e-mail address, also containing a domain name and a local part. Thus, a perfect conversion between IMXP and CPIM addressing can be achieved: @ <==> im:@ 2.3 Identifying PRESENTITIES CPIM defines an identifier format for a presentity that is a URI containing a domain name and a local part. The IMXP presence service [6] uses a presentity identifier format with the same form as an e-mail address, also containing a domain name and a local part. Thus, a perfect conversion between IMXP and CPIM presentity identifiers can be achieved: @ <==> pres:@ 2.4 WATCHER addressing CPIM and IMXP both use the same form for watcher addresses that they use for presentity identifiers, so the same mapping applies. 2.5 PRESENCE SERVICE addressing CPIM uses the presentity identifier or watcher address to locate the corresponding service. The IMXP presence service [6] uses a presence service address with the same form as an e-mail address, containing a domain name and a local part, but in which the local-part is fixed as "imxp=presence". When mapping IMXP to CPIM, the service address is not needed (having the same domain address part as the corresponding presenity identifier or watcher address). Klyne, et al Internet draft [Page 5] Instant Messaging using IMXP 18 October 2000 When mapping CPIM to IMXP, a service address is constructed using the domain part of the corresponding CPIM presence URI: pres:@ ==> imxp=presence@ 2.6 IMXP access provisioning RFC 2779 requires that there be mechanisms for authorizing who is allowed to perform various operations, or access private information. This requirement is not reflected in CPIM because it is seen as being handled locally within a domain. IMXP provides a flexible mechanism based on the IMXP access service [5]. IMXP components operating within a domain are required to check that the requested operation is allowed according to permissions lodged with the domain's access service. 2.7 Service goals The goals of the service defined here are: (a) to satisfy the requirements set out in RFC 2779 [1]. (b) to allow interoperability with other IM/P protocols using the common framework set out in CPIM [3]. (c) to allow simple text messages to be exchanged between instant messaging user agents. 3. Instant Message service IMXP message content is transfered as a MIME object [12] within a multipart/related, or as an XML element in an IMXP Data operation. The IMXP Data operation contains a URI-reference [14] to indicate the message content: a cid: URI is used to indicate another body part within an enclosing multipart/related, or a fragment identifier to indicate an XML element within the IMXP Data element. See section 4.1 of the IMXP core specification [4] for further details. Klyne, et al Internet draft [Page 6] Instant Messaging using IMXP 18 October 2000 3.1 Format of Instant Messages An instant message consists of a message header, based on RFC822 [15] encoded in XML [16], and a message content. The instant message header contains information about the message that is conveyed between message user agents, and not used by the message transfer mechanisms. This may include who the message is from, who it is addressed to, other parties to whom it has been copied, subject of the message, date the message was composed, etc. The message header also contains a reference to the message content, in the same fashion that an IMXP element references the entire message. Thus, an instant message can be constructed as a MIME multipart/related: Content-type: Multipart/related Content-Type: multipart/related; boundary="boundary"; start="<1@example.com>"; type="message/rfc822+xml" --boundary Content-Type: message/rfc822+xml Content-ID: <1@example.com> And this is the <message> text! Notes: o The RFC822 message in XML format is described more fully in a separate document [18]. o The 'content=' attribute of the element indicates a URI or fragment identifier that names the message content. o Headers are represented as XML elements, whose content is the corresponding header value. o Header field names are based on RFC822 header names, using all lower-case characters [15]. (XML element names are case sensitive [16].) The exception is element . o Header field names are associated with an XML namespace [17] identified as 'URN:IANA:message:rfc822:'. (This namespace identifier is based on a work-in-progress [19].) o Individual message header elements in the message header may appear in any order, except the element, which, if used, MUST be the last element in the message header. Klyne, et al Internet draft [Page 8] Instant Messaging using IMXP 18 October 2000 o Header contents are same syntax and meaning as corresponding RFC822 header contents [15], except that: - Characters are not limited to US-ASCII. UTF-8 charset encoding is used. - Address values are presented as URIs. Note that characters in URIs are drawn from a limited repertoire; the URI '%' escape sequence may be used to represent other characters that are legal for the URI scheme used [14]. - Encoded words (=?...?=) are not needed, and SHOULD NOT be used. o The 1st example above uses RFC822 as an XML namespace prefix [17]; any name may be used here. o The 2nd example above uses default XML namespace [17], so no namespace prefix needs to be used. o The XML reserved characters in the 2nd example above are replaced by their corresponding XML entity references ('<' and '>'). o When message content is included in the message header, its MIME content-type is indicated by the 'type=' attribute of the element. The charset for data is UTF-8 (i.e. inherited from the surrounding XML header). o Although theoretically possible in some cases, nested multipart/related structures MUST NOT be flattened. 3.2 Content of an instant message The instant message format described above allows any kind of message content. Instant message service endpoints MUST be able to process message content that is provided as "text/plain;charset=US-ASCII" or "text/plain;charset=UTF-8" [13]. Endpoints SHOULD support the "Format=flowed" parameter, per RFC 2646 [11]. Klyne, et al Internet draft [Page 9] Instant Messaging using IMXP 18 October 2000 3.3 Sending an instant message An instant message is sent using the IMXP Data operation to the desired recipient address [4]. CPIM does not provide for end-to-end confirmation of receipt, so if a 'statusRequest' option is specified with "targetHop='final'" or 'targetHop=all', it SHOULD NOT also indicate "seeNoEvil='false'" or the IMXP/CPIM gateway may fail the message. 4. Presence service 4.1 Format of presence information Presence information is transferred in the form of a element [6] in an IMXP Data operation [4]. 4.2 Subscribing to receive presence information Subscription to presence information is achieved by sending a element [6] in an IMXP Data operation [4]. The response is an IMXP Data operation with a element [6] containing the desired information, followed by further such messages each time the indicated presence information changes. Updates to the presence information continue to be provided until the specified duration elapses, or a element is send to the presence service. CPIM uses a 'subscribe' operation, and returns a confirmation 'response' operation and at least one separate 'notify' operation, until the duration elapses or an 'Unsubscribe' operation is issued. An IMXP/CPIM gateway should handle creation and correlation of the separate IMXP 'response' operation. 4.3 Polling presence information Polling for presence information is achieved by issuing a zero- duration subscription. 4.4 Publishing presence information And endpoint publishes presence information by sending a element in an IMXP Data operation to its presence service. Klyne, et al Internet draft [Page 10] Instant Messaging using IMXP 18 October 2000 The presence service propagates presence information by sending elements to endpoints that have requested them. CPIM handles propagation of presence information by issuing 'Notify' operations. (Publication or updating of presence information by an endpoint is not covered by CPIM.) 4.5 Watcher operations IMXP watcher operations are performed by sending , , and elements [6] in IMXP Data operations [4]. (CPIM does not describe distribution of watcher information, as this is regarded as local to an administrative domain.) 5. Internationalization considerations IMXP uses the address format defined by RFC822, which limits characters in address local parts to US-ASCII. This means that many foreign language personal names cannot be represented. Similarly, the characters that can be used in domain names are currently severely constrained. Work is under way to define internationalized forms for domain names. Message content is tagged using standard MIME capabilities (charset parameter for text data [13], and Content-language header for language tagging [22]). IMXP instant messaging user agents are required to be able to process UTF-8 coded character data, but that does not necessarily mean that all characters received can be displayed. When message content is included in the XML message header, language tagging can be achieved by including an 'xml:lang=' attribute [16] in the element. Presence information is represented using XML. Support for UTF-8 character encoding is requiured for human readable parts of the presence information. Klyne, et al Internet draft [Page 11] Instant Messaging using IMXP 18 October 2000 6. Security considerations The primary form of security provided by IMXP is hop-by-hop, requiring that each IMXP relay must be trusted to handle the messages it receives. The IMXP authorization framework is described in section 4.5 of the IMXP core specification [4], and its use for IMXP instant messaging is elaborated below. Endpoints may choose to use additional end-to-end security, such as S/MIME [23] or OpenPGP [24] by bilateral arrangement. Such usage is not defined by this specification. 6.1 Security provisioning IMXP security is based on BEEP session security profiles, coupled with IMXP authorization policies that allow BEEP peers to act as designated IMXP endpoints or relays for designated domains. IMXP instant messaging endpoints MUST support the following: o BEEP SASL security profile using the DIGEST-MD5 mechanism [25] [26]. This allows the endpoint to authenticate itself to a relay. o If confidentiality is required: BEEP TLS security profile, using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite[9]. o authenticate with BEEP peer identities that are the same as their endpoint identifier. An endpoint thus authenticated should be trusted to originate and receive messages and requests for the indicated endpoint. IMXP instant messaging relays MUST support the following: o For communication with IMXP endpoints, support the BEEP security profile noted above. o For communication with IMXP endpoints or other IMXP relays: BEEP TLS security profile, using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite [9]. o IMXP relays MUST authenticate themselves to IMXP endpoints and other IMXP relays as "imxp=mesh@". A relay thus authenticated should be trusted to originate and receive messages and requests for the indicated domain. Klyne, et al Internet draft [Page 12] Instant Messaging using IMXP 18 October 2000 NOTE: IMXP instant messaging endpoint support for confidentiality is optional, but if confidentiality is supported then the indicated TLS security profile MUST be supported. IMXP instant messaging relays are required to support confidentiality when communicating with other relays, using the TLS mechanism indicated. Security mechanisms other than those noted above may be used by bilateral agreement. Support for additional security profiles can be discovered through BEEP Greeting messages [8]. 7. Acknowledgements The authors thank the following for their contributions: Ned Freed provided valuable advice on the choice of TLS cipher suite. 8. References [1] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [3] Crocker, D.H., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rose, M.T., Rosenberg, J., Sparks, R. and H. Sugano, "A Common Profile for Instant Messaging (CPIM)", draft-thenine-im-common-00 (work in progress), August 2000. [4] Rose, M.T., Klyne, G. and D.H. Crocker, "The IMXP", draft-mrose-imxp-core-01 (work in progress), September 2000. [5] Rose, M.T., Klyne, G. and D.H. Crocker, "The IMXP Access Service" draft-mrose-imxp-access-01 (work in progress), September 2000. Klyne, et al Internet draft [Page 13] Instant Messaging using IMXP 18 October 2000 [6] Rose, M.T., Klyne, G. and D.H. Crocker, "The IMXP Presence Service" draft-mrose-imxp-presence-01 (work in progress), September 2000. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [8] Rose, M.T., "The Blocks Extensible Exchange Protocol Framework", draft-ietf-beep-framework-02 (work in progress), September 2000. [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [10] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [11] Gellens, R., "The Text/Plain Format Parameter", RFC 2646, August 1999. [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046 November 1996. [14] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Klyne, et al Internet draft [Page 14] Instant Messaging using IMXP 18 October 2000 [15] Crocker, D., "Standard for the format of ARPA Internet text messages", RFC 822, STD 11, August 1982. [16] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", W3C recommendation: , 10 February 1998. [17] Tim Bray, Dave Hollander, and Andrew Layman "Namespaces in XML", W3C recommendation: , 14 January 1999. [18] Klyne, G., Crocker, D.H. and M.T. Rose, "XML coding of RFC822 messages" draft-klyne-message-rfc822-xml-00 (work in progress), October 2000. [19] Mealling, M., [[[URN namespace for IANA registries]]], (work in progress), 2000 [20] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. [21] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [22] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. (Defines Content-language header.) [23] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. Klyne, et al Internet draft [Page 15] Instant Messaging using IMXP 18 October 2000 [24] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [25] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [26] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000. 9. Authors' addresses Graham Klyne (editor) Content Technologies Ltd. 1220 Parkview, Arlington Business Park Theale Reading, RG7 4SA United Kingdom Telephone: +44 118 930 1300 Facsimile: +44 118 930 1301 E-mail: GK@ACM.ORG Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US Telephone: +1 707 789 3700 E-mail: mrose@invisible.net URI: http://invisible.net/ Klyne, et al Internet draft [Page 16] Instant Messaging using IMXP 18 October 2000 David H. Crocker Brandenburg Consulting 675 Spruce Drive Sunnyvale, CA 94086 US Telephone: +1 408 246 8253 E-mail: dcrocker@brandenburg.com URI: http://www.brandenburg.com/ Appendix A: Amendment history 00a 05-Oct-2000 Memo initially created. 00b 10-Oct-2000 Filled in details of IMXP usage in relation to CPIM. Clarified some presence addressing details. Picked some security profiles. 00c 11-Oct-2000 Introduced message format based on RFC822 encoded with XML. Cosmetic fixes. 00d 11-Oct-2000 Drafted internationalization and security considerations sections. Completed CPIM/IMXP mapping appendices. Revisit security provisioning: moved to "Security considerations" section as it applies to both messaging and presence; specify only authentication is mandatory to implement for endpoint-relay mode, using SASL DIGEST-MD5. 00e 12-Oct-2000 More cosmetic fixes. Delete CPIM/IMXP mapping appendices -- these are now in the IMXP core documents. 01a 18-Oct-2000 Change mandatory-to-implement TLS cipher suite doe relays to TLS_RSA_WITH_3DES_EDE_CBC_SHA. Punt issue of MIME headers in XML message header to separate document. Change content type Message/RFC822|XML to Message/RFC822+XML (per more recent XML-MIME types specification). Clarify that nested Multipart/related structures may not be flattened. Klyne, et al Internet draft [Page 17] Instant Messaging using IMXP 18 October 2000 Full copyright statement Copyright (C) The Internet Society 2000. 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. Klyne, et al Internet draft [Page 18]