summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2778.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2778.txt')
-rw-r--r--doc/rfc/rfc2778.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc2778.txt b/doc/rfc/rfc2778.txt
new file mode 100644
index 0000000..8994dbd
--- /dev/null
+++ b/doc/rfc/rfc2778.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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]
+