Internet Engineering Task Force impp wg Internet Draft M.Day,J.Rosenberg draft-day-impp-model-00.txt.txt Lotus/Bell Labs February 17, 1999 Expires: August 1999 A Model for Presence 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. Abstract This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. 1 Introduction An instant messaging and presence system allows for users to subscribe to each other and be notified of changes in state, and for users to send each other short instant messages. A number of requirements and protocols have been proposed to support it [1] [2] [3] [4] [5] [6] [7]. To facilitate development of a suite of protocols to provide this service, we feel it is valuable to first develop a model for the system. The model consists of the various entities involved, descriptions of the basic functions they provide, M.Day,J.Rosenberg [Page 1] Internet Draft Presence Model February 17, 1999 and most importantly, definition of a vocabulary which can be used to facilitate discussion. 2 Model 1. A PRESENCE SERVICE accepts, stores, and distributes PRESENCE INFORMATION. 2. A PRESENTITY (presence entity) is an entity that provides PRESENCE INFORMATION to a PRESENCE SERVICE. We don't like to coin new words, but "presentity" seemed worthwhile so as to have an unambiguous term for the entity of interest to a presence service. Note that the presentity is not (usually) located in the presence service: the presence service only has a recent version of the presentity's presence information. The presentity initiates changes in the presence information to be distributed by the presence service. 3. A WATCHER is an entity that requests PRESENCE INFORMATION about a PRESENTITY. Note that WATCHER does not imply SUBSCRIBER, below. 4. A SUBSCRIBER is a form of WATCHER that has asked the PRESENCE SERVICE to notify immediately of changes in the PRESENCE INFORMATION of one or more PRESENTITIES. 5. A PRINCIPAL is a human, program, or collection of humans and/or programs that chooses to appear to the PRESENCE SERVICE as a single actor, distinct from all other PRINCIPALs. Again, we need a clear notion of the actors outside the system. "Principal" seems as good a term as any. 6. A PRINCIPAL may own zero or more PRESENTITIES, manipulated via a PRESENCE USER AGENT (PUA). This is essentially a model/view distinction: the PRESENTITY is the model of the presence being exposed, and is independent of its manifestation in any user interface. 7. A PRINCIPAL may own zero or more WATCHERS, manipulated via a WATCHER USER AGENT (WUA). As with PUA and PRESENTITY, the distinction here is intended to isolate the core functionality of a WATCHER from how it might appear to be manipulated by a product. M.Day,J.Rosenberg [Page 2] Internet Draft Presence Model February 17, 1999 8. A BUDDY LIST is the combination of a PUA and WUA for a single PRINCIPAL, using a single PRESENTITY and a single SUBSCRIBER. This makes a buddy list is a special case of a more general architecture. 9. A PRESENCE SERVICE may require authentication of PRESENTITIES and/or WATCHERS. 10. A PRESENCE SERVICE may have different authentication requirements for different PRESENTITIES. 11. A PRESENCE SERVICE may have different authentication requirements for different WATCHERS, and may also have different authentication requirements for different PRESENTITIES being watched by a single WATCHER. 12. A PRESENCE SERVICE makes PRESENCE INFORMATION available to WATCHERS, subject to ACCESS RULES. For each PRESENTITY's PRESENCE INFORMATION, the applicable ACCESS RULES are manipulated by the PUA of the PRINCIPAL that owns the PRESENTITY. We need some way of talking about hiding presence information from people. 13. A PRESENCE SERVICE makes WATCHER INFORMATION available to PRESENTITIES, subject to VISIBILITY RULES. For each WATCHER's WATCHER INFORMATION, the applicable VISIBILITY RULES are manipulated by the WUA of the PRINCIPAL that owns the WATCHER. 14. PRESENCE INFORMATION consists of a STATUS and a MARKUP. The STATUS is expected to change more rapidly than the MARKUP, and the PRESENCE SERVICE may limit its size. A change in STATUS causes only the STATUS to be transmitted to SUBSCRIBERS. At the base level of functionality, any change to the MARKUP causes the entire MARKUP to be transmitted to SUBSCRIBERS. However, a SUBSCRIBER can negotiate with the PRESENCE SERVICE to transmit only the changed portion of a MARKUP. 15. An INSTANT MESSAGE is a MIME-encoded entity of known size. 16. A distinguished part of the MARKUP is the INSTANT INBOX, which indicates whether and how the PRESENTITY's PRINCIPAL can receive an INSTANT MESSAGE. The STATUS and INSTANT INBOX information are sufficient to determine whether the PRINCIPAL appears ready to accept the INSTANT MESSAGE. M.Day,J.Rosenberg [Page 3] Internet Draft Presence Model February 17, 1999 The definition is pretty loose about exactly how any of this works, even leaving open the possibility of reusing parts of the email infrastructure for instant messaging. 17. A PRESENCE SERVICE may have an internal structure involving multiple NETWORK ADDRESSES. A PRESENTITY or WATCHER may be redirected to a different NETWORK ADDRESS while still retaining logical connectivity to the same PRESENCE SERVICE. 18. A PRESENCE SERVICE may have an internal structure involving PROXIES, or hidden NETWORK ADDRESSES. A PRESENTITY or WATCHER may interact with PROXY at a particular NETWORK ADDRESS, which in turn may interact with one or more other NETWORK ADDRESSES. 19. A PRESENCE SERVICE may have an internal structure involving other PRESENCE SERVICES, which may be independently accessible in their own right as well as being reachable through the initial PRESENCE SERVICE. 3 Conclusion This document has provided a model for a presence and instant messaging system. 4 Bibliography [1] G. Mohr, "WhoDP: widely hosted object data protocol," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress. [2] M. Day, ""HTTP envy" and presence information protocols," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress. [3] L. Dusseault, "Addressing and location for RVP," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress. [4] M. Day, "Requirements for presence and instant messaging," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress. [5] J. Rosenberg and H. Schulzrinne, "SIP for presence," Internet Draft, Internet Engineering Task Force, Nov. 1998. Work in progress. [6] L. Dusseault and M. Calsyn, "Presence information protocol requirements," Internet Draft, Internet Engineering Task Force, Feb. M.Day,J.Rosenberg [Page 4] Internet Draft Presence Model February 17, 1999 1998. Work in progress. [7] M. Calsyn, L. Dusseault, and G. Mohr, "RVP: a presence notification protocol," Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in progress. 5 Authors Addresses Mark Day Lotus Corporation Jonathan Rosenberg Lucent Technologies, Bell Laboratories 101 Crawfords Corner Rd. Holmdel, NJ 07733 Rm. 4C-526 email: jdrosen@bell-labs.com M.Day,J.Rosenberg [Page 5]