This page serves as an index of terms used throughout the Website That Have Dection IN Other Sections. The Links Direct You To Where Each Term is defined.
.
A-MAL Allow List BL Block List Challenge Server Initiated Ping DS Dispatch Server FL Forward List Group ID Number identifying a particular contact list group Version Number Number identifying the current version of personal details MD5 A message digest algorithm Message The MSG command N-ZNewline Used to end commands and fields NS Notification Server Official Client Microsoft's MSN / .NET client Payload Command Multi-Line Command Parameter Additional information included in a command Ping Client Initiated Ping RL Reverse List / r / n Newline Presence Present information about a principal, such as THEIR ON-line State Sb Switchboard Trid Transaction ID: RFC 2778
Network Working Group M. DayRequest for Comments: 2778 Lotuscategory: 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.
AbstractThis 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.
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 Appers 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 innubs.
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 .,..........................
-------------- 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. Figure 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 | | | | Subscriber | ------------ ---------- Fig. 3b: Notification (STEP 2)
------------------------- | Presence service | | P2 | ------------- -------------- | P2 V ------------ ------------ | P2 | P1-> p2 | | presentity | | ---------- ------------
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 Intertion Between Presence Service, Presentities, And Watchers. Presence Information is carried by the Presence Protocol.
An Instant Message Protocol Defines The Intertion 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 present 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 claim means 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 specification mens. 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 take no position on whether the INBOX USER 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.. 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 seen 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 Implement As Direct Communication Between Sender and Instant Inbox.
- May Have An Inters The Initial Instant Message Service.
NOTIFICATION: A Message Sent from The Presence Service To a Subscriber When there is a change.
Motivation: We delibely 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 resch meaning is not defined by this model. Contrast with closed.
Other Presence Markup: Any Additional Information Of a presentity. The model. 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 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 Implement As Direct Communication Among Presentity and Watchers.
- May Have An Internal Structure Involving Other Presectly Accessible in Their OWN Right As Well AS Being Reachable Through The Initial Presence Service.
Presence Tuple: Conscesses of A Status, An Optional Communication Address, And Optional Other Presence: 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 do not 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.: .............................
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.
.
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 Individe Unit of a Presence Service or Instant Message Service.
Spam: Unwanted Instant Messages.
SPOFING: a Principal Improperly Imitation 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 The 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 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 Watches 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 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 to isolate,. Watcher, And Presence Service Are Colocated or Distributed Across Machines.
4. Security Considances
. 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 Arecture. 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.
