Network working group G. Klyne, Content Technologies Ltd. Internet draft D. H. Crocker, Brandenburg Consulting M. T. Rose, Invisible Worlds, Inc. 1 June 2001 Expires: November 2001 Instant Messaging using APEX 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". 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 2001. All Rights Reserved. Abstract This document describes how to provision an instant text messaging and presence service using the APEX relaying service. 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 1 June 2001 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 APEX .....................................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 APEX 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 ........................8 3.3 Sending an instant message ...........................8 4. Presence service.........................................8 4.1 Format of presence information .......................8 4.2 Subscribing to receive presence information ..........8 4.3 Polling presence information .........................9 4.4 Publishing presence information ......................9 4.5 Watcher operations ...................................9 5. Internationalization considerations......................9 6. Security considerations..................................10 6.1 Security provisioning ................................10 7. Acknowledgements.........................................11 8. References...............................................11 9. Authors' addresses.......................................14 Appendix A: Mapping summary for CPIM presence service.......15 Appendix B: Amendment history...............................17 Full copyright statement....................................18 Klyne, et al Internet draft [Page 2] Instant Messaging using IMXP 1 June 2001 1. Introduction This document describes how to provision an instant text messaging and presence service using APEX [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 APEX-provisioned instant text messaging service in terms of the basic CPIM Message operation. Section 4 describes the APEX-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 1 June 2001 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 the APEX relaying mesh. 2.1 Overview of APEX The basic philosophy of APEX 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 APEX relaying 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 relaying 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 APEX identically over variety of transports. o Other applications may use the same relaying mesh. Asynchronous near-real-time message exchange with accessible, predictable behaviour is applicable to a number of loosely-coupled applications, of which instant text messaging and presence information distribution are just two. Klyne, et al Internet draft [Page 4] Instant Messaging using IMXP 1 June 2001 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. APEX uses an endpoint address with the same form as an email address, also containing a domain name and a local part. Thus, a perfect conversion between APEX 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 APEX 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 APEX and CPIM presentity identifiers can be achieved: @ <==> pres:@ 2.4 WATCHER addressing CPIM and APEX 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 APEX 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 "apex=presence". When mapping APEX to CPIM, the service address is not needed (having the same domain address part as the corresponding presentity identifier or watcher address). Klyne, et al Internet draft [Page 5] Instant Messaging using IMXP 1 June 2001 When mapping CPIM to APEX, a service address is constructed using the domain part of the corresponding CPIM presence URI: pres:@ ==> apex=presence@ 2.6 APEX 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. APEX provides a flexible mechanism based on the APEX access service [5]. APEX relay 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 APEX message content is transfered as a MIME object [12] within a multipart/related, or as an XML element in an APEX Data operation. The APEX 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 (#fragment) to indicate an XML element within the APEX element. See section 4.1 of the APEX core specification [4] for further details. Klyne, et al Internet draft [Page 6] Instant Messaging using IMXP 1 June 2001 3.1 Format of Instant Messages The format of an instant message is that defined for CPIM messages [3,18]. Example of instant message in APEX protocol: B: MSG 1 1 . 42 1234 A: Content-Type: multipart/related; boundary="boundary"; A: start="<1@example.com>"; A: type="application/beep+xml" A: A: --boundary A: Content-Type: application/beep+xml A: Content-ID: <1@example.com> A: A: A: A: A: A: --boundary M: Content-type: message/cpim M: Content-Transfer-Encoding: binary M: Content-ID: <2@example.com> M: M: From: MR SANDERS M: To: Depressed Donkey M: Date: 2000-12-13T13:40:00-08:00 M: Subject: Message subject M: M: Content-type: text/plain; charset=utf-8 M: Content-ID: <1234567890@100akerwood.com> M: M: Here is the text of my message. A: --boundary-- B: END In the above example: B: is used to prefix lines that are part of the BEEP protocol framing structure, A: is used to prefix lines that are part of the APEX protocol envelope, and M: is used to prefix lines that are part of the instant message format, including message headers and content. Klyne, et al Internet draft [Page 7] Instant Messaging using IMXP 1 June 2001 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]. 3.3 Sending an instant message An instant message is sent using the APEX 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 APEX/CPIM gateway may fail the message. 4. Presence service This section outlines the provisioning of a CPIM compliant presence service using APEX. Appendix A contains further specific details about the mapping of presence related message content. 4.1 Format of presence information [[[This subject to change when CPIM message format is defined.]]] Presence information is transferred in the form of a element [6] in an APEX Data operation [4]. 4.2 Subscribing to receive presence information Subscription to presence information is achieved by sending a element [6] in an APEX Data operation [4]. The response is an APEX 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 sent to the presence service. Klyne, et al Internet draft [Page 8] Instant Messaging using IMXP 1 June 2001 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 APEX/CPIM gateway should handle creation and correlation of the separate APEX 'response' operation. 4.3 Polling presence information Polling for presence information is achieved by issuing a zero- duration subscription. 4.4 Publishing presence information An endpoint publishes presence information by sending a element in an APEX Data operation to its presence service. 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 APEX watcher operations are performed by sending , , and elements [6] in APEX Data operations [4]. (CPIM does not describe distribution of watcher information, as this is regarded as local to an administrative domain.) 5. Internationalization considerations APEX 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]). APEX 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. Klyne, et al Internet draft [Page 9] Instant Messaging using IMXP 1 June 2001 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. 6. Security considerations The primary form of security provided by APEX is hop-by-hop, requiring that each APEX relay must be trusted to handle the messages it receives. The APEX authorization framework is described in section 4.5 of the APEX core specification [4], and its use for APEX 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 APEX security is based on BEEP session security profiles, coupled with APEX authorization policies that allow BEEP peers to act as designated APEX endpoints or relays for designated domains. APEX 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. APEX instant messaging relays MUST support the following: o For communication with APEX endpoints, support the BEEP security profile noted above. Klyne, et al Internet draft [Page 10] Instant Messaging using IMXP 1 June 2001 o For communication with APEX endpoints or other APEX relays: BEEP TLS security profile, using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite [9]. o APEX relays MUST authenticate themselves to APEX endpoints and other APEX relays as "apex=mesh@". A relay thus authenticated should be trusted to originate and receive messages and requests for the indicated domain. NOTE: APEX instant messaging endpoint support for confidentiality is optional, but if confidentiality is supported then the indicated TLS security profile MUST be supported. APEX 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. Klyne, et al Internet draft [Page 11] Instant Messaging using IMXP 1 June 2001 [4] Rose, M.T., Klyne, G. and D.H. Crocker, "The Application Exchange Core", draft-ietf-apex-core-00 (work in progress), April 2001. [5] Rose, M.T., Klyne, G. and D.H. Crocker, "The APEX Access Service" draft-ietf-apex-access-00 (work in progress), April 2001. [6] Rose, M.T., Klyne, G. and D.H. Crocker, "The APEX Presence Service" draft-ietf-apex-presence-00 (work in progress), April 2001. [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-10 (work in progress), December 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. Klyne, et al Internet draft [Page 12] Instant Messaging using IMXP 1 June 2001 [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. [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] Atkins, D., and G. Klyne, "Common Presence and Instant Messaging: Message Format" draft-ietf-impp-cpim-msgfmt-01.txt (work in progress), May 2001. [19] Mealling, M., "A URN Namespace for IANA Registered Protocol Elements", draft-mealling-iana-urn-00.txt (work in progress), November 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. Klyne, et al Internet draft [Page 13] Instant Messaging using IMXP 1 June 2001 [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. [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 Klyne, et al Internet draft [Page 14] Instant Messaging using IMXP 1 June 2001 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/ 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: Mapping summary for CPIM presence service APEX to CPIM Presence Information: CPIM presence APEX presence ================== ================== entityInfo publisherInfo tuple->destination tuple->destination tuple->status if currentTime >= tuple->lastUpdate then 'closed' else 'open' tuple content tuple->tupleInfo CPIM to APEX Presence Information: APEX presence CPIM presence ================== ================== publisher notify->target lastUpdate currentTime publisherInfo empty tuple->destination tuple->destination tuple->availableUntil if status = 'closed' then currentTime else muchLater tuple->tupleInfo empty tuple content empty Klyne, et al Internet draft [Page 15] Instant Messaging using IMXP 1 June 2001 Requesting a Subscription: CPIM subscribe APEX subscribe ================== ================== watcher data->originator target publisher duration duration transID transID Transmitting Presence Information: CPIM notify APEX publish ================== ================== watcher data->originator target publisher transID transID Terminating a Subscription: CPIM unsubscribe APEX terminate ================== ================== watcher data->originator target stateful lookup based on transID transID transID Klyne, et al Internet draft [Page 16] Instant Messaging using IMXP 1 June 2001 Appendix B: Amendment history 00a 11-Apr-2001 Changed name to . Changed names of other APEX drafts in the references. 00b 01-Jun-2001 Changed message format to reflect CPIM work in progress. Previous draft: 00a 24-Dec-2000 Submitted for publication under new name; no significant changes. 01a 03-Jan-2001 Changed IMXP to APEX. Added CPIM mapping details that were previously in the IMXP presence document. Note that message format is likely to change substantially. Various small editorial changes. 01b 04-Jan-2001 Editorial/terminology fixes. Previous draft: 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. Klyne, et al Internet draft [Page 17] Instant Messaging using IMXP 1 June 2001 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. 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. Klyne, et al Internet draft [Page 18]