    Network Working Group                                          M. Day
    Request for Comments: 2778                                      Lotus
    Category: Informational                                  J. Rosenberg
                                                              dynamicsoft
                                                                H. Sugano
                                                                  Fujitsu
                                                            February 2000

                   A Model for Presence and Instant Messaging

    Status of this Memo

       This memo provides information for the Internet community.  It does
       not specify an Internet standard of any kind.  Distribution of this
       memo is unlimited.

    Copyright Notice

       Copyright (C) The Internet Society (2000).  All Rights Reserved.

    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.

    1. 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. 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.

       We note that the purpose of this model is to be descriptive and
       universal: we want the model to map reasonably onto all of the
       systems that are informally described as presence or instant
       messaging systems. The model is not intended to be prescriptive or
       achieve interoperability: an element that appears in the model will
       not necessarily be an element of an interoperable protocol, and may
       not even be a good idea.

    Day, et al.                  Informational                      [Page 1]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

       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.  The overview includes diagrams, 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.

    2. 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 two services: a PRESENCE SERVICE and an INSTANT
       MESSAGE SERVICE. The PRESENCE SERVICE serves to accept information,
       store it, and distribute it.  The information stored is
       (unsurprisingly) PRESENCE INFORMATION. The INSTANT MESSAGE SERVICE
       serves to accept and deliver INSTANT MESSAGES to INSTANT INBOXES.

    2.1 PRESENCE SERVICE

       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.

    Day, et al.                  Informational                      [Page 2]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

                        +---------------------------+
                        |     PRESENCE SERVICE      |
                        |                           |
                        +---------------------------+
                            ^                 |
                            |                 |
                            |                 v
                     +------------+       +------------+
                     | PRESENTITY |       |  WATCHER   |
                     +------------+       +------------+

                     Fig. 1: Overview of Presence 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
       special kind of FETCHER is one that fetches information on a regular
       basis.  This is called a POLLER.

                  +----------------WATCHER---------------+
                  |                                      |
                  |  +----FETCHER---+  +--SUBSCRIBER--+  |
                  |  |              |  |              |  |
                  |  | +--POLLER--+ |  |              |  |
                  |  | |          | |  |              |  |
                  |  | +----------+ |  |              |  |
                  |  +--------------+  +--------------+  |
                  +--------------------------------------+

                       Fig. 2: Varieties of WATCHER

       The PRESENCE SERVICE also has WATCHER INFORMATION about WATCHERS and
       their activities in terms of fetching or subscribing to PRESENCE
       INFORMATION.  The PRESENCE SERVICE may also distribute WATCHER
       INFORMATION to some WATCHERS, using the same mechanisms that are
       available for distributing PRESENCE INFORMATION.

       Changes to PRESENCE INFORMATION are distributed to SUBSCRIBERS via
       NOTIFICATIONS. Figures 3a through 3c show the flow of information as
       a piece of PRESENCE INFORMATION is changed from P1 to P2.

    Day, et al.                  Informational                      [Page 3]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

                       +---------------------------+
                       |     PRESENCE SERVICE      |
                       |            P1             |
                       +---------------------------+

                    +------------+       +------------+
                    |   P1->P2   |       |     P1     |
                    | PRESENTITY |       | SUBSCRIBER |
                    +------------+       +------------+

                       Fig. 3a: NOTIFICATION (Step 1)

                       +---------------------------+
                       |     PRESENCE SERVICE      |
                       |          P1->P2           |
                       +---------------------------+
                           ^
                           |P2
                    +------------+       +------------+
                    |     P2     |       |    P1      |
                    | PRESENTITY |       | SUBSCRIBER |
                    +------------+       +------------+

                       Fig. 3b: NOTIFICATION (Step 2)

                       +---------------------------+
                       |     PRESENCE SERVICE      |
                       |            P2             |
                       +---------------------------+
                                               |P2
                                               v
                    +------------+       +------------+
                    |     P2     |       |   P1->P2   |
                    | PRESENTITY |       | SUBSCRIBER |
                    +------------+       +------------+

                       Fig. 3c: NOTIFICATION (Step 3)

    2.2 INSTANT MESSAGE SERVICE

       The INSTANT MESSAGE SERVICE also has two distinct sets of "clients":
       SENDERS and INSTANT INBOXES. A SENDER provides INSTANT MESSAGES to
       the INSTANT MESSAGE SERVICE for delivery. Each INSTANT MESSAGE is

    Day, et al.                  Informational                      [Page 4]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

       addressed to a particular INSTANT INBOX ADDRESS, and the INSTANT
       MESSAGE SERVICE attempts to deliver the message to a corresponding
       INSTANT INBOX.

                     +---------------------------+
                     |  INSTANT MESSAGE SERVICE  |
                     |                           |
                     +---------------------------+
                         ^                 |
                         |                 |
                         |                 v
                  +------------+       +---------------+
                  |   SENDER   |       | INSTANT INBOX |
                  +------------+       +---------------+

                Fig. 4: Overview of Instant Message Service

    2.3 Protocols

       A PRESENCE PROTOCOL defines the interaction between PRESENCE SERVICE,
       PRESENTITIES, and WATCHERS. PRESENCE INFORMATION is carried by the
       PRESENCE PROTOCOL.

       An INSTANT MESSAGE PROTOCOL defines the interaction between INSTANT
       MESSAGE SERVICE, SENDERS, and INSTANT INBOXES. INSTANT MESSAGES are
       carried by the INSTANT MESSAGE PROTOCOL.

       In terms of this model, we believe that the IMPP working group is
       planning to develop detailed requirements and specifications for the
       structure and formats of the PRESENCE PROTOCOL, PRESENCE INFORMATION,
       INSTANT MESSAGE PROTOCOL, and INSTANT MESSAGES.

    2.4 Formats

       The model defines the PRESENCE INFORMATION to consist of an arbitrary
       number of elements, called PRESENCE TUPLES. Each such element
       consists of a STATUS marker (which might convey information such as
       online/offline/busy/away/do not disturb), an optional COMMUNICATION
       ADDRESS, and optional OTHER PRESENCE MARKUP.  A COMMUNICATION ADDRESS
       includes a COMMUNICATION MEANS and a CONTACT ADDRESS. One type of
       COMMUNICATION MEANS, and the only one defined by this model, is
       INSTANT MESSAGE SERVICE.  One type of CONTACT ADDRESS, and the only
       one defined by this model, is INSTANT INBOX ADDRESS. However, other
       possibilities exist: a COMMUNICATION MEANS might indicate some form
       of telephony, for example, with the corresponding CONTACT ADDRESS
       containing a telephone number.

    Day, et al.                  Informational                      [Page 5]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

          +------------------------------------+
          | PRESENCE INFORMATION               |
          +------------------------------------+
           | +-------------------------------+
           =>| PRESENCE TUPLE                |
           | +-------------------------------+
           |   | +-------------------------+
           |   =>| STATUS                  |
           |   | +-------------------------+
           |   | +-------------------------+
           |   =>| COMMUNICATION ADDRESS   |
           |   | +-------------------------+
           |   |     | +-----------------+
           |   |     =>| CONTACT MEANS   |
           |   |     | +-----------------+
           |   |     | +-----------------+
           |   |     =>| CONTACT ADDRESS |
           |   |       +-----------------+
           |   | +-------------------------+
           |   =>| OTHER MARKUP            |
           |     +-------------------------+
           | +-------------------------------+
           =>| PRESENCE TUPLE                |
           | +-------------------------------+
           |   | +-------------------------+
           |   =>| STATUS                  |
           |   | +-------------------------+
           |   | +-------------------------+
           |   =>| COMMUNICATION ADDRESS   |
           |   | +-------------------------+
           |   |     | +-----------------+
           |   |     =>| CONTACT MEANS   |
           |   |     | +-----------------+
           |   |     | +-----------------+
           |   |     =>| CONTACT ADDRESS |
           |   |       +-----------------+
           |   | +-------------------------+
           |   =>| OTHER MARKUP            |
           |     +-------------------------+
           | +-------------------------------+
           =>| PRESENCE TUPLE                |
           | +-------------------------------+
           |    ...

            Fig. 5: The structure of PRESENCE INFORMATION

    Day, et al.                  Informational                      [Page 6]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

       STATUS is further defined by the model to have at least two states
       that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT
       MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will
       not be accepted. OPEN and CLOSED may also be applicable to other
       COMMUNICATION MEANS -- OPEN mapping to some state meaning "available"
       or "open for business" while CLOSED means "unavailable" or "closed to
       business." The model allows STATUS to include other values, which may
       be interpretable by programs or only by persons.  The model also
       allows STATUS to consist of single or multiple values.

    2.5 Presence and its effect on Instant Messages

       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.

    2.6 PRINCIPALS and their agents

       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
       (INBOX USER AGENT; SENDER USER AGENT; PRESENCE USER AGENT; WATCHER
       USER AGENT). 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 (respectively, INSTANT
       INBOX; SENDER; PRESENTITY; WATCHER).

    Day, et al.                  Informational                      [Page 7]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

                       +---------------------------+
                       |     PRESENCE SERVICE      |
                       +---------------------------+
                           ^                   |
                           | PRESENCE PROTOCOL |
                           |                   v
                    +------------+       +------------+
                    | PRESENTITY |       |  WATCHER   |
                    +------------+       +------------+
                          ^                   ^
                          |                   |
                          |                   |
            o      +--------------+      +-------------+      o
           /|\  -->| PRESENCE UA  |      | WATCHER UA  |<--  /|\
            X      +--------------+      +-------------+      X

       (PRINCIPAL)                                        (PRINCIPAL)

                        Fig. 6: A presence system

                      +---------------------------+
                      |  INSTANT MESSAGE SERVICE  |
                      +---------------------------+
                          ^                    |
                        IM|   INSTANT MESSAGE  |IM
                          |       PROTOCOL     v
                   +------------+        +---------------+
                   |   SENDER   |        | INSTANT INBOX |
                   +------------+        +---------------+
                         ^                      ^
                         |                      |
                         |                      |
           o      +-------------+       +------------------+      o
          /|\  -->|  SENDER UA  |       |  INBOX UA        |<--  /|\
           X      +-------------+       +------------------+      X

       (PRINCIPAL)                                           (PRINCIPAL)

                    Fig. 7: An instant messaging system

    Day, et al.                  Informational                      [Page 8]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

    2.7 Examples

       A simple example of applying the model is to describe a generic
       "buddy list" application. These applications typically expose the
       user's presence to others, and make it possible to see the presence
       of others. So we could describe a buddy list as the combination of a
       PRESENCE USER AGENT and WATCHER USER AGENT for a single PRINCIPAL,
       using a single PRESENTITY and a single SUBSCRIBER.

       We could then extend our example to instant messaging and describe a
       generic "instant messenger" as essentially a buddy list with
       additional capabilities for sending and receiving instant messages.
       So an instant messenger would be the combination of a PRESENCE USER
       AGENT, WATCHER USER AGENT, INBOX USER AGENT, and SENDER 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.

    3. 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.

       CLOSED: a distinguished value of the STATUS marker. In the context of
          INSTANT MESSAGES, this value means that the associated INSTANT
          INBOX ADDRESS, if any, corresponds to an INSTANT INBOX that is
          unable to accept an INSTANT MESSAGE.  This value may have an
          analogous meaning for other COMMUNICATION MEANS, but any such
          meaning is not defined by this model. Contrast with OPEN.

       COMMUNICATION ADDRESS: consists of COMMUNICATION MEANS and CONTACT
          ADDRESS.

       COMMUNICATION MEANS: indicates a method whereby communication can
          take place. INSTANT MESSAGE SERVICE is one example of a
          COMMUNICATION MEANS.

       CONTACT ADDRESS: a specific point of contact via some COMMUNICATION
          MEANS. When using an INSTANT MESSAGE SERVICE, the CONTACT ADDRESS
          is an INSTANT INBOX ADDRESS.

    Day, et al.                  Informational                      [Page 9]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

       DELIVERY RULES: constraints on how an INSTANT MESSAGE 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.

       FETCHER: a form of WATCHER that has asked the PRESENCE SERVICE to for
          the PRESENCE INFORMATION of one or more PRESENTITIES, but has not
          asked for a SUBSCRIPTION to be created.

       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. This manipulation includes fetching messages, deleting
          messages, and setting DELIVERY RULES. We deliberately take no
          position on whether the INBOX USER AGENT, INSTANT INBOX, and
          INSTANT MESSAGE 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 small size, to be
          sent to an INSTANT INBOX.

          Motivation: We do not define "small" but we seek in this
          definition to avoid the possibility of transporting an arbitrary-
          length stream labelled as an "instant message."

    Day, et al.                  Informational                     [Page 10]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

       INSTANT MESSAGE PROTOCOL: The messages that can be exchanged between
          a SENDER USER AGENT and an INSTANT MESSAGE SERVICE, or between an
          INSTANT MESSAGE SERVICE and an INSTANT INBOX.

       INSTANT MESSAGE SERVICE: accepts and delivers INSTANT MESSAGES.

          -- May require authentication of SENDER USER AGENTS and/or INSTANT
             INBOXES.

          -- May have different authentication requirements for different
             INSTANT INBOXES, and may also have different authentication
             requirements for different INSTANT INBOXES controlled by a
             single PRINCIPAL.

          -- May have an internal structure involving multiple SERVERS
             and/or PROXIES. There may be complex patterns of redirection
             and/or proxying while retaining logical connectivity to a
             single INSTANT MESSAGE SERVICE. Note that an INSTANT MESSAGE
             SERVICE does not require having a distinct SERVER -- the
             service may be implemented as direct communication between
             SENDER and INSTANT INBOX.

          -- May have an internal structure involving other INSTANT MESSAGE
             SERVICES, which may be independently accessible in their own
             right as well as being reachable through the initial INSTANT
             MESSAGE SERVICE.

       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.

       OPEN: a distinguished value of the STATUS marker. In the context of
          INSTANT MESSAGES, this value means that the associated INSTANT
          INBOX ADDRESS, if any, corresponds to an INSTANT INBOX that is
          ready to accept an INSTANT MESSAGE.  This value may have an
          analogous meaning for other COMMUNICATION MEANS, but any such
          meaning is not defined by this model. Contrast with CLOSED.

       OTHER PRESENCE MARKUP: any additional information included in the
          PRESENCE INFORMATION of a PRESENTITY. The model does not define
          this further.

       POLLER: a FETCHER that requests PRESENCE INFORMATION on a regular
          basis.

    Day, et al.                  Informational                     [Page 11]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

       PRESENCE INFORMATION: consists of one or more PRESENCE TUPLES.

       PRESENCE PROTOCOL: The messages that can be exchanged between a
          PRESENTITY and a PRESENCE SERVICE, or a WATCHER and a PRESENCE
          SERVICE.

       PRESENCE SERVICE: accepts, stores, and distributes PRESENCE
          INFORMATION.

          -- May require authentication of PRESENTITIES, and/or WATCHERS.

          -- 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 an internal structure involving multiple SERVERS
             and/or PROXIES. There may be complex patterns of redirection
             and/or proxying while retaining logical connectivity to a
             single PRESENCE SERVICE. Note that a PRESENCE SERVICE does not
             require having a distinct SERVER -- the service may be
             implemented as direct communication among PRESENTITY and
             WATCHERS.

          -- 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 TUPLE: consists of a STATUS, an optional COMMUNICATION
          ADDRESS, and optional OTHER PRESENCE MARKUP.

       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.

    Day, et al.                  Informational                     [Page 12]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

          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 that communicates PRESENCE INFORMATION, INSTANT
          MESSAGES, SUBSCRIPTIONS and/or NOTIFICATIONS to another SERVER.
          Sometimes a PROXY acts on behalf of a PRESENTITY, WATCHER, or
          INSTANT INBOX.

       SENDER: source of INSTANT MESSAGES to be delivered by the INSTANT
          MESSAGE SERVICE.

       SENDER USER AGENT: means for a PRINCIPAL to manipulate zero or more
          SENDERS.

       SERVER: an indivisible unit of a PRESENCE SERVICE or INSTANT MESSAGE
          SERVICE.

       SPAM: unwanted INSTANT MESSAGES.

       SPOOFING: a PRINCIPAL improperly imitating another PRINCIPAL.

       STALKING: using PRESENCE INFORMATION to infer the whereabouts of a
          PRINCIPAL, especially for malicious or illegal purposes.

       STATUS: a distinguished part of the PRESENCE INFORMATION of a
          PRESENTITY. STATUS has at least the mutually-exclusive values OPEN
          and CLOSED, which have meaning for the acceptance of INSTANT
          MESSAGES, and may have meaning for other COMMUNICATION MEANS.
          There may be other values of STATUS that do not imply anything
          about INSTANT MESSAGE acceptance. These other values of STATUS may
          be combined with OPEN and CLOSED or they may be mutually-exclusive
          with those values.

    Day, et al.                  Informational                     [Page 13]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

          Some implementations may combine STATUS with other entities. For
          example, an implementation might make an INSTANT INBOX ADDRESS
          visible only when the INSTANT INBOX can accept an INSTANT MESSAGE.
          Then, the existence of an INSTANT INBOX ADDRESS implies OPEN,
          while its absence implies CLOSED.

       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: requests PRESENCE INFORMATION about a PRESENTITY, or WATCHER
          INFORMATION about a WATCHER, from the PRESENCE SERVICE. Special
          types of WATCHER are FETCHER, POLLER, 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.

          Motivation: If a PRESENTITY wants to know who knows about it, it
          is not enough to examine only information about SUBSCRIPTIONS. A
          WATCHER might repeatedly fetch information without ever
          subscribing. Alternately, a WATCHER might repeatedly subscribe,
          then cancel the SUBSCRIPTION.  Such WATCHERS should be visible to
          the PRESENTITY if the PRESENCE SERVICE offers WATCHER INFORMATION,
          but will not be appropriately visible if the WATCHER INFORMATION
          includes only SUBSCRIPTIONS.

       WATCHER USER AGENT: means for a PRINCIPAL to manipulate zero or more
          WATCHERS controlled by that PRINCIPAL.

    Day, et al.                  Informational                     [Page 14]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

          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.

    4. Security Considerations

       This document provides a model and vocabulary for systems with
       certain intrinsic security issues. In particular, presence and
       instant messaging systems must deal with "the three S's": STALKING,
       SPOOFING, and SPAM. ACCESS RULES, VISIBILITY RULES, and WATCHER
       INFORMATION are intended to deal with STALKING.  The several kinds of
       authentication mentioned for INSTANT MESSAGE SERVICE and PRESENCE
       SERVICE are intended to deal with SPOOFING. DELIVERY RULES are
       intended to deal with SPAM.

    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, by the participants in the Cambridge, MA meeting on
       June 11, 1999, and by Roy Salisbury, who contributed the original
       version of Figure 5. The authors gratefully acknowledge their
       assistance.

    Day, et al.                  Informational                     [Page 15]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

    7. Authors' Addresses

       Mark Day
       SightPath, Inc.
       135 Beaver Street
       Waltham, MA 02452
       USA

       EMail: mday@alum.mit.edu
       (Formerly Mark_Day@lotus.com)

       Jonathan Rosenberg
       dynamicsoft
       200 Executive Drive
       Suite 120
       West Orange, NJ 07046

       Email: jdrosen@dynamicsoft.com

       Hiroyasu Sugano
       Fujitsu Laboratories Ltd.
       64 Nishiwaki, Ohkubo-cho
       Akashi 674-8555
       Japan

       EMail: suga@flab.fujitsu.co.jp

    Day, et al.                  Informational                     [Page 16]

    RFC 2778       A Model for Presence and Instant Messaging  February 2000

    8. 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.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Day, et al.                  Informational                     [Page 17]