INTERNET-DRAFT Mark Day Expires October 23, 1999 Lotus Jonathan Rosenberg Bell Labs A Model for Presence and Instant Messaging draft-ietf-impp-model-00.txt 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. 1. 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. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging. 2. Introduction A presence and instant messaging system allows 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 [WHODP, ENVY, RVP-ADDR, RPIM, SIP-PIP, PIPR, RVP]. To facilitate development of a suite of protocols to provide this service, we believe that 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, and most importantly, definition of a vocabulary which can be used to facilitate discussion. In this document, each element of the model appears in upper case (e.g., PRESENCE SERVICE). No term in lower case or mixed case is intended to be a term of the model. The first part of this document is intended as an overview of the model, and terms are presented in an order that is intended to help the reader understand the relationship between elements. The second part of the document is the actual definition of the model, with terms presented in alphabetical order for ease of reference. The overview is intended to be helpful but is not definitive; it may contain inadvertent differences from the definitions in the model. For any such difference, the definition(s) in the model are taken to be correct, rather than the explanation(s) in the overview. 3. Overview The model is intended to provide a means for understanding, comparing, and describing systems that support the services typically referred to as presence and instant messaging. It consists of a number of named entities that appear, in some form, in existing systems. No actual implementation is likely to have every entity of the model as a distinct part. Instead, there will almost always be parts of the implementation that embody two or more entities of the model. However, different implementations may combine entities in different ways. The model defines a PRESENCE SERVICE. This service serves to accept information, store it, and distribute it. The information stored is (unsurprisingly) PRESENCE INFORMATION. The PRESENCE SERVICE has two distinct sets of "clients" (remember, these may be combined in an implementation, but treated separately in the model). One set of clients, called PRESENTITIES, provides PRESENCE INFORMATION to be stored and distributed. The other set of clients, called WATCHERS, receives PRESENCE INFORMATION from the service. There are two kinds of WATCHERS, called FETCHERS and SUBSCRIBERS. A FETCHER simply requests the current value of some PRESENTITY's PRESENCE INFORMATION from the PRESENCE SERVICE. In contrast, a SUBSCRIBER requests notification from the PRESENCE SERVICE of (future) changes in some PRESENTITY's PRESENCE INFORMATION. A presence protocol defines the interaction between PRESENCE SERVICE, PRESENTITIES, and WATCHERS. A presence markup defines the structure and format of the PRESENCE INFORMATION that is carried on the presence protocol. The model defines the PRESENCE INFORMATION to consist of a STATUS marker (which might convey information such as online/offline/busy/away/do not disturb), an optional INSTANT INBOX ADDRESS (further described below), and optional OTHER PRESENCE MARKUP. The STATUS marker is further defined by the model to have at least two states that interact with INSTANT MESSAGE delivery -- one in which INSTANT MESSAGES will be accepted, and one in which INSTANT MESSAGES will not be accepted. An INSTANT INBOX is a receptacle for INSTANT MESSAGES. Its INSTANT INBOX ADDRESS is the information that can be included in PRESENCE INFORMATION to define how an INSTANT MESSAGE should be delivered to that INSTANT INBOX. As noted above, certain values of the STATUS marker indicate whether INSTANT MESSAGES will be accepted at the INSTANT INBOX. The model does not otherwise constrain the delivery mechanism or format for instant messages. Reasonable people can disagree about whether this omission is a strength or a weakness of this model. This model includes other elements that are useful in characterizing how the protocol and markup work. PRINCIPALS are the people, groups, and/or software in the "real world" outside the system that use the system as a means of coordination and communication. It is entirely outside the model how the real world maps onto PRINCIPALS -- the system of model entities knows only that two distinct PRINCIPALS are distinct, and two identical PRINCIPALS are identical. A PRINCIPAL interacts with the system via one of several user agents. As usual, the different kinds of user agents are split apart in this model even though most implementations will combine at least some of them. A user agent is purely coupling between a PRINCIPAL and some core entity of the system (PRESENTITY, WATCHER, or PRESENCE SERVICE). 4. Model ACCESS RULES: constraints on how a PRESENCE SERVICE makes PRESENCE INFORMATION available to WATCHERS. For each PRESENTITY's PRESENCE INFORMATION, the applicable ACCESS RULES are manipulated by the PRESENCE USER AGENT of a PRINCIPAL that controls the PRESENTITY. Motivation: We need some way of talking about hiding presence information from people. BUDDY LIST: the combination of a PRESENCE USER AGENT and WATCHER USER AGENT for a single PRINCIPAL, using a single PRESENTITY and a single SUBSCRIBER. Motivation: This makes the familiar notion of "buddy list" a special case of a more general architecture. DELIVERY RULES: constraints on how a PRESENCE SERVICE delivers received INSTANT MESSAGES to INSTANT INBOXES. For each INSTANT INBOX, the applicable DELIVERY RULES are manipulated by the INBOX USER AGENT of a PRINCIPAL that controls the INSTANT INBOX. Motivation: We need a way of talking about filtering instant messages. INBOX USER AGENT: means for a PRINCIPAL to manipulate zero or more INSTANT INBOXES controlled by that PRINCIPAL. Motivation: This is intended to isolate the core functionality of an INSTANT INBOX from how it might appear to be manipulated by a product. We deliberately take no position on whether the INBOX USER AGENT, INSTANT INBOX, and PRESENCE SERVICE are colocated or distributed across machines. INSTANT INBOX: receptacle for INSTANT MESSAGES intended to be read by the INSTANT INBOX's PRINCIPAL. INSTANT INBOX ADDRESS: indicates whether and how the PRESENTITY's PRINCIPAL can receive an INSTANT MESSAGE in an INSTANT INBOX. The STATUS and INSTANT INBOX ADDRESS information are sufficient to determine whether the PRINCIPAL appears ready to accept the INSTANT MESSAGE. Motivation: 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. INSTANT MESSAGE: an identifiable unit of data, of known size, to be sent to an INSTANT INBOX. INSTANT MESSENGER: the combination of a PRESENCE USER AGENT, WATCHER USER AGENT, INBOX USER AGENT, and SENDING USER AGENT for a single PRINCIPAL, using a single PRESENTITY, single SUBSCRIBER, and single INSTANT INBOX, with the PRESENTITY's PRESENCE INFORMATION including an INSTANT INBOX ADDRESS that leads to the INSTANT INBOX. NOTIFICATION: a message sent from the PRESENCE SERVICE to a SUBSCRIBER when there is a change in the PRESENCE INFORMATION of some PRESENTITY of interest, as recorded in one or more SUBSCRIPTIONS. Motivation: We deliberately take no position on what part of the changed information is included in a NOTIFICATION. OTHER PRESENCE MARKUP: any additional information included in the PRESENCE INFORMATION of a PRESENTITY. The model does not define this further. PRESENCE INFORMATION: consists of a STATUS, an optional INSTANT INBOX ADDRESS, and optional OTHER PRESENCE MARKUP. PRESENCE SERVICE: accepts, stores, and distributes PRESENCE INFORMATION. -- May require authentication of PRESENTITIES, WATCHERS, and/or INSTANT INBOXES. -- May have different authentication requirements for different PRESENTITIES. -- May have different authentication requirements for different WATCHERS, and may also have different authentication requirements for different PRESENTITIES being watched by a single WATCHER. -- May have different authentication requirements for different INSTANT INBOXES, and may also have different authentication requirements for different INSTANT INBOXES being watched by a single WATCHER. -- May have an internal structure involving multiple SERVERS: that is, a PRESENTITY or WATCHER may be redirected to a different SERVER while still retaining logical connectivity to the same PRESENCE SERVICE. -- May have an internal structure involving PROXIES: that is, a PRESENTITY, WATCHER, INSTANT INBOX, or SENDING USER AGENT may interact with a PROXY, which in turn may interact with one or more other SERVERS. -- 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. PRESENCE USER AGENT: means for a PRINCIPAL to manipulate zero or more PRESENTITIES. Motivation: 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. In addition, we deliberately take no position on how the PRESENCE USER AGENT, PRESENTITY, and PRESENCE SERVICE are colocated or distributed across machines. PRESENTITY (presence entity): provides PRESENCE INFORMATION to a PRESENCE SERVICE. Motivation: 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. PRINCIPAL: 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. Motivation: We need a clear notion of the actors outside the system. "Principal" seems as good a term as any. PROXY: a SERVER which communicates PRESENCE INFORMATION, INSTANT MESSAGES, SUBSCRIPTIONS and NOTIFICATIONS to another SERVER. Sometimes a PROXY acts on behalf of a PRESENTITY, WATCHER, or INSTANT INBOX. SENDING USER AGENT: means for a PRINCIPAL to send an INSTANT MESSAGE to an INSTANT INBOX. Motivation: Note that sending a message does not require a long-term relationship between the PRESENCE SERVICE and the sending PRINCIPAL, so there is no entity analogous to PRESENTITY, WATCHER, or INSTANT INBOX for the purpose of sending. Instead, we need only distinguish between the PRINCIPAL, the program used by the sender (the SENDING USER AGENT), and the PRESENCE SERVICE that accepts and delivers the message. SERVER: an indivisible unit of a PRESENCE SERVICE. STATUS: a distinguished part of the PRESENCE INFORMATION of a PRESENTITY. At least one value of STATUS means that any associated INSTANT INBOX ADDRESS is ready to accept INSTANT MESSAGES. At least one other value of STATUS means that any associated INSTANT INBOX ADDRESS will not accept any INSTANT MESSAGES. There may be other values of STATUS that do not imply anything about instant message acceptance. SUBSCRIBER: a form of WATCHER that has asked the PRESENCE SERVICE to notify it immediately of changes in the PRESENCE INFORMATION of one or more PRESENTITIES. SUBSCRIPTION: the information kept by the PRESENCE SERVICE about a SUBSCRIBER's request to be notified of changes in the PRESENCE INFORMATION of one or more PRESENTITIES. VISIBILITY RULES: constraints on how a PRESENCE SERVICE makes WATCHER INFORMATION available to WATCHERS. For each WATCHER's WATCHER INFORMATION, the applicable VISIBILITY RULES are manipulated by the WATCHER USER AGENT of a PRINCIPAL that controls the WATCHER. Motivation: We need a way of talking about hiding watcher information from people. WATCHER: somehow requests PRESENCE INFORMATION about a PRESENTITY. Special types of WATCHER are FETCHER and SUBSCRIBER. WATCHER INFORMATION: information about WATCHERS that have received PRESENCE INFORMATION about a particular PRESENTITY within a particular recent span of time. WATCHER INFORMATION is maintained by the PRESENCE SERVICE, which may choose to present it in the same form as PRESENCE INFORMATION; that is, the service may choose to make WATCHERS look like a special form of PRESENTITY. WATCHER USER AGENT: means for a PRINCIPAL to manipulate zero or more WATCHERS controlled by that PRINCIPAL. Motivation: As with PRESENCE USER AGENT 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. As previously, we deliberately take no position on whether the WATCHER USER AGENT, WATCHER, and PRESENCE SERVICE are colocated or distributed across machines. 5. Conclusion This document has provided a model for a presence and instant messaging system. The purpose of the model is to provide a common vocabulary for the further work of defining and implementing interoperable presence and instant messaging protocols. 6. Acknowledgements This document has been improved by comments from Jesse Vincent and Colin Benson. The authors gratefully acknowledge their assistance. 7. References [ENVY] M. Day. ''HTTP Envy'' and Presence Information Protocols. Internet-Draft draft-day-envy-00.txt [PIPR] M. Calsyn, L. Dusseault. Presence Information Protocol Requirements. Internet-Draft draft-dusseault-pipr-00.txt [RPIM] M. Day. Requirements for Presence and Instant Messaging. Internet-Draft draft-day-rpim-00.txt [RVP-ADDR] L. Dusseault, G. Mohr. Addressing and Location for RVP. Internet-Draft draft-dusseault-rvp-addr-00.txt [RVP] M. Calsyn, L. Dusseault, G. Mohr. RVP: A Presence Notification Protocol. Internet-Draft draft-calsyn-rvp-01.txt [SIP-PIP] J. Rosenberg, H.Schulzrinne. SIP For Presence. Internet-Draft draft-rosenberg-sip-pip-00.txt [WHODP] G. Mohr. WhoDP: Widely Hosted Object Data Protocol. Internet-Draft draft-mohr-whodp-00.txt 8. Authors' Addresses Mark Day Lotus Development Corporation 55 Cambridge Parkway Cambridge, MA 02142 email: Mark_Day@lotus.com Jonathan Rosenberg Lucent Technologies, Bell Laboratories 101 Crawfords Corner Rd. Holmdel, NJ 07733 Rm. 4C-526 email: jdrosen@bell-labs.com