INTERNET-DRAFT J. Overbey Actilon Internet H. Sugano S. Fujimoto Fujitsu F. Mazzoldi A. Diacakis Personity, Inc. G. Hudson MIT J. D. Ramsdell The MITRE Corporation Draft: draft-overbey-prim-overview-00.txt Expires: September 2002 March 2002 Presence and Instant Messaging Protocol (PRIM) Overview 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 is an individual contribution for consideration by the PRIM Working Group of the Internet Engineering Task Force. Comments should be submitted to the prim@ml.fujitsulabs.com mailing list or joverbey@actilon.com. Copyright (C) The Internet Society (2002). All Rights Reserved. Overbey et al. [Page 1] INTERNET DRAFT PRIM Overview March 2002 Abstract This document presents an overview of the PRIM protocol architecture, which follows from the IMPP model and requirements set forth in RFC2778/2779. It is intended as prerequisite reading for implementers of the PRIM client-server and server-server protocols, which are described in separate documents. Table of Contents 1. Introduction..................................................2 1.1 PRIM Design Principles....................................3 2. Architecture..................................................3 2.1 Distributive Architecture.................................4 2.2 Presence Model............................................4 2.3 Instant Messaging Model...................................5 References.......................................................6 Authors' Addresses...............................................6 1. Introduction PRIM, the PResence and Instant Messaging protocols, provide a standard communication mechanism for Instant Messaging and Presence (IM/P) services. Instant messaging services provide for the real- time exchange of short text, audio, and/or video messages. Presence services disseminate information about the status of users; they are usually used to indicate whether or not users are available for instant messaging. The PRIM protocols are designed to facilitate IM/P services both within a single enterprise and across domains. PRIM consists of two protocols, a client-server protocol and a server-server protocol; each of these protocols contains commands for both presence and instant messaging service. These protocols are described individually in separate documents. The client-server protocol allows clients of the PRIM IM/P services to communicate with IM/P servers to exchange presence information and instant messages; it is mainly used within a single administrative domain. The server-server protocol allows for communication between IM/P servers, whether they be in the same administrative domain or different ones. The PRIM specifications are based on RFC2778, which describes a model for IM/P services, and RFC2779, which specifies requirements for such services. PRIM is also designed to conform to the Common Profile for Instant Messaging (CPIM) specifications. This enables users of PRIM services to exchange presence information and instant Overbey et al. [Page 2] INTERNET DRAFT PRIM Overview March 2002 messages with users of services which use other CPIM compatible protocols. Before proceeding with this document, it is essential that the reader become familiar with the model and vocabulary presented in RFC2778 and RFC2779. In the remainder of this document, words in ALL CAPS should be interpreted under the definitions given in these documents. 1.1 PRIM Design The PRIM specifications are based on the following design principles. Note that the latter is only relevant to the client- server protocol. o Transfer protocol directly atop of TCP PRIM assumes TCP as the basic transport mechanism for INSTANT MESSAGES and PRESENCE INFORMATION. TCP provides a sufficiently reliable transport infrastructure, which is required by both instant messaging and presence services. o Long-lived client/server connections PRIM uses long-lived client/server TCP connections in order to receive INSTANT MESSAGES and PRESENCE INFORMATION NOTIFICATIONS. Note that this is the prevailing model used by most Presence and IM systems at the time of writing. It brings the following advantages: - Overhead is reduced, because authentication is performed once: at the beginning of the connection. This is important, for example, when PRESENCE INFORMATION NOTIFICATIONS occur frequently. - Connections are firewall-friendly. USER AGENTS initiate connections from inside a firewall; once established, these connections can carry notifications and messages initiated from the outside. 2. Architecture This section describes the architecture used by both the client- server and server-server protocols. Overbey et al. [Page 3] INTERNET DRAFT PRIM Overview March 2002 2.1 Distributive Architecture Under the PRIM architecture, a PRINCIPAL is identified by a PRESENTITY/WATCHER and SENDER/INBOX which enjoy PRESENCE and INSTANT MESSAGING SERVICES. A Service Domain is an administrative entity which encompasses all of the PRINCIPALS and PRESENCE and INSTANT MESSAGING SERVICES administered by a single enterprise. The Service Domain for a particular PRINCIPAL is known as that PRINCIPAL's Home Domain. A PRINCIPAL connects to its Home Domain via a USER AGENT to access PRESENCE and INSTANT MESSAGING SERVICES. Thus, a Service Domain includes PRESENCE and/or INSTANT MESSAGING SERVERS together with USER AGENTS. A USER AGENT only communicates with the SERVERS in its Home Domain, and the PRIM client-server protocol is used to facilitate communication between the USER AGENT and SERVERS. A SERVER can communicate with other SERVERS using the PRIM server-server protocol. The commands transferred by this protocol are either initiated by the SERVER itself or relayed on behalf of USER AGENTS. These SERVERS may be located in different Service Domains. For example, suppose that an INSTANT MESSAGE needs to be relayed from a user, John, to another user, Jane, in the same Service Domain. JohnÆs USER AGENT connects to the IM SERVER for his Home Domain and transmits the INSTANT MESSAGE to the SERVER using the PRIM client-server protocol. The IM SERVER realizes that the recipient, Jane, is also in its Service Domain and transmits the message to her INSTANT INBOX. JaneÆs USER AGENT receives the INSTANT MESSAGE via the client-server protocol. Suppose, however, that John wants to transmit a message to Vivian, who is located in another Service Domain. Again, JohnÆs USER AGENT transmits the INSTANT MESSAGE to the IM SERVER in his Home Domain. This server, using DNS, discovers the address of the IM SERVER in VivianÆs Home Domain and, using the server-server protocol, transmits the INSTANT MESSAGE to that SERVER, which delivers it to VivianÆs INSTANT INBOX. VivianÆs USER AGENT receives the INSTANT MESSAGE via the client-server protocol. 2.2 Presence Model 2.2.1 Presence Servers Presence servers are the primary components of a PRESENCE SERVICE. A presence server in a Service Domain stores and manages PRESENCE INFORMATION published by PRESENTITIES in that domain and SUBSCRIPTIONS from SUBSCRIBERS to the PRESENTITIES. The SUBSCRIBERS Overbey et al. [Page 4] INTERNET DRAFT PRIM Overview March 2002 may be located in the same domain or may subscribe from different domains. [*** DELETED: If a presence server receives a request for a PRESENTITY in a different domain, it forwards the request to the target domain using an inter-domain server-server connection. *** Is this sort of proxying a good idea? Need discussion. If kept, this should be in the server-server draft, not here. ***] When the PRESENCE INFORMATION of a PRESENTITY changes, NOTIFICATION messages will be issued by the presence server to SUBSCRIBERS to that particular PRESENTITY. 2.2.2 Presence Subscriptions WATCHERS can subscribe to a PRESENTITY in order to receive NOTIFICATIONS when the PRESENCE INFORMATION of that PRESENTITY changes. SUBSCRIPTIONS have a duration under which they are in effect. This duration is specified at the time that the subscription is placed or renewed. Once that period elapses, the SUBSCRIPTION has to be either renewed by the SUBSCRIBER or else it must be removed by the PRESENTITY's Presence Server. This renewal may be either issued by the USER AGENT, or by the SUBSCRIBER's Presence Server on behalf of the SUBSCRIBER. 2.2.3 Presence Information PRESENCE INFORMATION transported by the PRIM protocol consists of one or more PRESENCE TUPLEs, as defined by the IMPP model document [RFC2778]. PRIM adopts the CPIM Presence Information Data Format [CPIM-PIDF] as its presence data format. 2.3 Instant Messaging Model INSTANT MESSAGING SERVICE provides a functionality of sending and receiving INSTANT MESSAGES for PRINCIPALS. USER AGENTS are able to exchange INSTANT MESSAGES with a client-server connection to the INSTANT MESSAGING SERVERS. An INSTANT MESSAGING SERVER provides an INSTANT INBOX for receiving Instant Messages. When a USER AGENT wishes to start receiving INSTANT MESSAGES, it starts listening to that INSTANT INBOX. Conversely, when it no longer wishes to receive INSTANT MESSAGES from that INSTANT INBOX, it stops listening to the INBOX. Overbey et al. [Page 5] INTERNET DRAFT PRIM Overview March 2002 INSTANT INBOXes have two states, as described in RFC 2779: OPEN and CLOSED. An INBOX is OPEN when at least one PRINCIPAL is listening to that INBOX. It is CLOSED when there are no PRINCIPALS listening to the INBOX. If an INSTANT MESSAGE is sent to an INBOX that has multiple PRINCIPALS listening, the message is considered to be delivered successfully if at least one PRINCIPAL receives it. References [CPIM] D. Crocker et al., "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-cpim-01.txt, Work in Progress. [CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-00.txt, Work in Progress. [CPIM-PIDF] H. Sugano et al., "CPIM Presence Information Data Format", draft-ietf-impp-cpim-pidf-02.txt, Work in Progress. [RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [RFC2779] M.Day, S.Aggarwal, G.Mohr, and J.Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. Authors' Addresses J. Overbey joverbey@actilon.com Actilon Internet 1258 Dover Cape Girardeau, MO 63701 USA H. Sugano sugano.h@jp.fujitsu.com Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674 Japan S. Fujimoto shingo_fujimoto@jp.fujitsu.com Overbey et al. [Page 6] INTERNET DRAFT PRIM Overview March 2002 Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674 Japan F. Mazzoldi flo@personity.com Personity, Inc. 4516 Henry Street, Suite 113 Pittsburgh PA 15213 USA A. Diacakis thanos@personity.com Personity, Inc. 4516 Henry Street, Suite 113 Pittsburgh, PA 15213 USA G. Hudson ghudson@mit.edu Massachusetts Institue of Technology Cambridge, MA 02139 USA J. D. Ramsdell ramsdell@mitre.org The MITRE Corporation 202 Burlington Road Bedford, MA 01730-1420 USA Full Copyright Statement Copyright (C) The Internet Society (2002). 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 Overbey et al. [Page 7] INTERNET DRAFT PRIM Overview March 2002 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Overbey et al. [Page 8]