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]
`
`Apple 1025
`U.S. Pat. 8,243,723
`
`

`
`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 M