INTERNET-DRAFT                                               Mark Day
Expires October 23, 1999                                        Lotus

                                                   Jonathan Rosenberg
                                                            Bell Labs

                A Model for Presence and Instant Messaging

                        draft-ietf-impp-model-00.txt

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

1. Abstract

This document defines an abstract model for a presence and instant
messaging system. It defines the various entities involved, defines
terminology, and outlines the services provided by the system. The
goal is to provide a common vocabulary for further work on
requirements for protocols and markup for presence and instant
messaging.

2. Introduction

A presence and instant messaging system allows users to subscribe to
each other and be notified of changes in state, and for users to send
each other short instant messages. A number of requirements and
protocols have been proposed to support it [WHODP, ENVY, RVP-ADDR,
RPIM, SIP-PIP, PIPR, RVP].  To facilitate development of a suite of
protocols to provide this service, we believe that it is valuable to
first develop a model for the system. The model consists of the
various entities involved, descriptions of the basic functions they
provide, and most importantly, definition of a vocabulary which can be
used to facilitate discussion.

In this document, each element of the model appears in upper case
(e.g., PRESENCE SERVICE). No term in lower case or mixed case is
intended to be a term of the model.

The first part of this document is intended as an overview of the
model, and terms are presented in an order that is intended to help
the reader understand the relationship between elements. The second
part of the document is the actual definition of the model, with terms
presented in alphabetical order for ease of reference.

The overview is intended to be helpful but is not definitive; it may
contain inadvertent differences from the definitions in the model. For
any such difference, the definition(s) in the model are taken to be
correct, rather than the explanation(s) in the overview.

3. Overview

The model is intended to provide a means for understanding, comparing,
and describing systems that support the services typically referred to
as presence and instant messaging. It consists of a number of named
entities that appear, in some form, in existing systems. No actual
implementation is likely to have every entity of the model as a
distinct part. Instead, there will almost always be parts of the
implementation that embody two or more entities of the model. However,
different implementations may combine entities in different ways.

The model defines a PRESENCE SERVICE. This service serves to accept
information, store it, and distribute it.  The information stored is
(unsurprisingly) PRESENCE INFORMATION.

The PRESENCE SERVICE has two distinct sets of "clients" (remember,
these may be combined in an implementation, but treated separately in
the model).  One set of clients, called PRESENTITIES, provides
PRESENCE INFORMATION to be stored and distributed.  The other set of
clients, called WATCHERS, receives PRESENCE INFORMATION from the
service.  There are two kinds of WATCHERS, called FETCHERS and
SUBSCRIBERS. A FETCHER simply requests the current value of some
PRESENTITY's PRESENCE INFORMATION from the PRESENCE SERVICE. In
contrast, a SUBSCRIBER requests notification from the PRESENCE SERVICE
of (future) changes in some PRESENTITY's PRESENCE INFORMATION.

A presence protocol defines the interaction between PRESENCE SERVICE,
PRESENTITIES, and WATCHERS. A presence markup defines the structure
and format of the PRESENCE INFORMATION that is carried on the presence
protocol. The model defines the PRESENCE INFORMATION to consist of a
STATUS marker (which might convey information such as
online/offline/busy/away/do not disturb), an optional INSTANT INBOX
ADDRESS (further described below), and optional OTHER PRESENCE MARKUP.
The STATUS marker is further defined by the model to have at least two
states that interact with INSTANT MESSAGE delivery -- one in which
INSTANT MESSAGES will be accepted, and one in which INSTANT MESSAGES
will not be accepted.

An INSTANT INBOX is a receptacle for INSTANT MESSAGES. Its INSTANT
INBOX ADDRESS is the information that can be included in PRESENCE
INFORMATION to define how an INSTANT MESSAGE should be delivered to
that INSTANT INBOX. As noted above, certain values of the STATUS
marker indicate whether INSTANT MESSAGES will be accepted at the
INSTANT INBOX.  The model does not otherwise constrain the delivery
mechanism or format for instant messages. Reasonable people can
disagree about whether this omission is a strength or a weakness of
this model.

This model includes other elements that are useful in characterizing
how the protocol and markup work. PRINCIPALS are the people, groups,
and/or software in the "real world" outside the system that use the
system as a means of coordination and communication. It is entirely
outside the model how the real world maps onto PRINCIPALS -- the
system of model entities knows only that two distinct PRINCIPALS are
distinct, and two identical PRINCIPALS are identical.

A PRINCIPAL interacts with the system via one of several user
agents. As usual, the different kinds of user agents are split apart
in this model even though most implementations will combine at least
some of them. A user agent is purely coupling between a PRINCIPAL and
some core entity of the system (PRESENTITY, WATCHER, or PRESENCE
SERVICE).

4. Model

ACCESS RULES: constraints on how a PRESENCE SERVICE makes PRESENCE
    INFORMATION available to WATCHERS. For each PRESENTITY's PRESENCE
    INFORMATION, the applicable ACCESS RULES are manipulated by the
    PRESENCE USER AGENT of a PRINCIPAL that controls the PRESENTITY.

    Motivation: We need some way of talking about hiding presence
    information from people.

BUDDY LIST: the combination of a PRESENCE USER AGENT and WATCHER
    USER AGENT for a single PRINCIPAL, using a single PRESENTITY and a
    single SUBSCRIBER.

    Motivation: This makes the familiar notion of "buddy list" a
    special case of a more general architecture.

DELIVERY RULES: constraints on how a PRESENCE SERVICE delivers
    received INSTANT MESSAGES to INSTANT INBOXES. For each INSTANT INBOX,
    the applicable DELIVERY RULES are manipulated by the INBOX USER AGENT
    of a PRINCIPAL that controls the INSTANT INBOX.

    Motivation: We need a way of talking about filtering instant
    messages.

INBOX USER AGENT: means for a PRINCIPAL to manipulate zero or more
    INSTANT INBOXES controlled by that PRINCIPAL.

    Motivation: This is intended to isolate the core functionality of an
    INSTANT INBOX from how it might appear to be manipulated by a
    product. We deliberately take no position on whether the INBOX USER
    AGENT, INSTANT INBOX, and PRESENCE SERVICE are colocated or
    distributed across machines.

INSTANT INBOX: receptacle for INSTANT MESSAGES intended to be read by
    the INSTANT INBOX's PRINCIPAL.

INSTANT INBOX ADDRESS: indicates whether and how the PRESENTITY's
    PRINCIPAL can receive an INSTANT MESSAGE in an INSTANT INBOX. The
    STATUS and INSTANT INBOX ADDRESS information are sufficient to
    determine whether the PRINCIPAL appears ready to accept the INSTANT
    MESSAGE.

    Motivation: The definition is pretty loose about exactly how
    any of this works, even leaving open the possibility of reusing parts
    of the email infrastructure for instant messaging.

INSTANT MESSAGE: an identifiable unit of data, of known size, to be
    sent to an INSTANT INBOX.

INSTANT MESSENGER: the combination of a PRESENCE USER AGENT,
    WATCHER USER AGENT, INBOX USER AGENT, and SENDING USER AGENT for a
    single PRINCIPAL, using a single PRESENTITY, single SUBSCRIBER, and
    single INSTANT INBOX, with the PRESENTITY's PRESENCE INFORMATION
    including an INSTANT INBOX ADDRESS that leads to the INSTANT INBOX.

NOTIFICATION: a message sent from the PRESENCE SERVICE to a SUBSCRIBER
    when there is a change in the PRESENCE INFORMATION of some PRESENTITY
    of interest, as recorded in one or more SUBSCRIPTIONS. Motivation: We
    deliberately take no position on what part of the changed information
    is included in a NOTIFICATION.

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

PRESENCE INFORMATION: consists of a STATUS, an optional INSTANT INBOX
    ADDRESS, and optional OTHER PRESENCE MARKUP.

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

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

    -- May have different authentication requirements for different
    PRESENTITIES.

    -- May have different authentication requirements for different
    WATCHERS, and may also have different authentication requirements
    for different PRESENTITIES being watched by a single WATCHER.

    -- May have different authentication requirements for different
    INSTANT INBOXES, and may also have different authentication
    requirements for different INSTANT INBOXES being watched by a
    single WATCHER.

    -- May have an internal structure involving multiple SERVERS: that
    is, a PRESENTITY or WATCHER may be redirected to a different
    SERVER while still retaining logical connectivity to the same
    PRESENCE SERVICE.

    -- May have an internal structure involving PROXIES: that is, a
    PRESENTITY, WATCHER, INSTANT INBOX, or SENDING USER AGENT may
    interact with a PROXY, which in turn may interact with one or more
    other SERVERS.

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

PRESENCE USER AGENT: means for a PRINCIPAL to manipulate zero or more
    PRESENTITIES.

    Motivation: This is essentially a "model/view" distinction: the
    PRESENTITY is the model of the presence being exposed, and is
    independent of its manifestation in any user interface. In
    addition, we deliberately take no position on how the PRESENCE
    USER AGENT, PRESENTITY, and PRESENCE SERVICE are colocated or
    distributed across machines.

PRESENTITY (presence entity): provides PRESENCE INFORMATION to a
    PRESENCE SERVICE.

    Motivation: We don't like to coin new words, but "presentity"
    seemed worthwhile so as to have an unambiguous term for the entity
    of interest to a presence service. Note that the presentity is not
    (usually) located in the presence service: the presence service
    only has a recent version of the presentity's presence
    information.  The presentity initiates changes in the presence
    information to be distributed by the presence service.

PRINCIPAL: human, program, or collection of humans and/or programs
    that chooses to appear to the PRESENCE SERVICE as a single actor,
    distinct from all other PRINCIPALS.

    Motivation: We need a clear notion of the actors outside the
    system. "Principal" seems as good a term as any.

PROXY: a SERVER which communicates PRESENCE INFORMATION, INSTANT
    MESSAGES, SUBSCRIPTIONS and NOTIFICATIONS to another SERVER. Sometimes
    a PROXY acts on behalf of a PRESENTITY, WATCHER, or INSTANT INBOX.

SENDING USER AGENT: means for a PRINCIPAL to send an INSTANT MESSAGE
    to an INSTANT INBOX.

    Motivation: Note that sending a message does not require a long-term
    relationship between the PRESENCE SERVICE and the sending PRINCIPAL,
    so there is no entity analogous to PRESENTITY, WATCHER, or INSTANT
    INBOX for the purpose of sending. Instead, we need only distinguish
    between the PRINCIPAL, the program used by the sender (the SENDING
    USER AGENT), and the PRESENCE SERVICE that accepts and delivers the
    message.

SERVER: an indivisible unit of a PRESENCE SERVICE.

STATUS: a distinguished part of the PRESENCE INFORMATION
    of a PRESENTITY. At least one value of STATUS means that any
    associated INSTANT INBOX ADDRESS is ready to accept INSTANT
    MESSAGES. At least one other value of STATUS means that any
    associated INSTANT INBOX ADDRESS will not accept any INSTANT
    MESSAGES. There may be other values of STATUS that do not imply
    anything about instant message acceptance.

SUBSCRIBER: a form of WATCHER that has asked the PRESENCE SERVICE to
    notify it immediately of changes in the PRESENCE INFORMATION of one or
    more PRESENTITIES.

SUBSCRIPTION: the information kept by the PRESENCE SERVICE about a
    SUBSCRIBER's request to be notified of changes in the PRESENCE
    INFORMATION of one or more PRESENTITIES.

VISIBILITY RULES: constraints on how a PRESENCE SERVICE makes
    WATCHER INFORMATION available to WATCHERS. For each WATCHER's WATCHER
    INFORMATION, the applicable VISIBILITY RULES are manipulated by the
    WATCHER USER AGENT of a PRINCIPAL that controls the WATCHER.

    Motivation: We need a way of talking about hiding watcher information
    from people.

WATCHER: somehow requests PRESENCE INFORMATION about a
    PRESENTITY. Special types of WATCHER are FETCHER and SUBSCRIBER.

WATCHER INFORMATION: information about WATCHERS that have received
    PRESENCE INFORMATION about a particular PRESENTITY within a particular
    recent span of time. WATCHER INFORMATION is maintained by the PRESENCE
    SERVICE, which may choose to present it in the same form as PRESENCE
    INFORMATION; that is, the service may choose to make WATCHERS look
    like a special form of PRESENTITY.

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

    Motivation: As with PRESENCE USER AGENT and PRESENTITY, the
    distinction here is intended to isolate the core functionality of a
    WATCHER from how it might appear to be manipulated by a product. As
    previously, we deliberately take no position on whether the WATCHER
    USER AGENT, WATCHER, and PRESENCE SERVICE are colocated or distributed
    across machines.

5. Conclusion

This document has provided a model for a presence and instant
messaging system. The purpose of the model is to provide a common
vocabulary for the further work of defining and implementing
interoperable presence and instant messaging protocols.

6. Acknowledgements

This document has been improved by comments from Jesse Vincent and Colin
Benson. The authors gratefully acknowledge their assistance.

7. References

[ENVY] M. Day. ''HTTP Envy'' and Presence Information Protocols.
Internet-Draft draft-day-envy-00.txt

[PIPR] M. Calsyn, L. Dusseault. Presence Information Protocol
Requirements. Internet-Draft draft-dusseault-pipr-00.txt

[RPIM] M. Day. Requirements for Presence and Instant Messaging.
Internet-Draft draft-day-rpim-00.txt

[RVP-ADDR] L. Dusseault, G. Mohr. Addressing and Location for
RVP. Internet-Draft draft-dusseault-rvp-addr-00.txt

[RVP] M. Calsyn, L. Dusseault, G. Mohr. RVP: A Presence Notification
Protocol. Internet-Draft draft-calsyn-rvp-01.txt

[SIP-PIP] J. Rosenberg, H.Schulzrinne. SIP For Presence.
Internet-Draft draft-rosenberg-sip-pip-00.txt

[WHODP] G. Mohr. WhoDP: Widely Hosted Object Data Protocol.
Internet-Draft draft-mohr-whodp-00.txt

8. Authors' Addresses

Mark Day
Lotus Development Corporation
55 Cambridge Parkway
Cambridge, MA 02142
email: Mark_Day@lotus.com

Jonathan Rosenberg
Lucent Technologies, Bell Laboratories
101 Crawfords Corner Rd.
Holmdel, NJ 07733
Rm. 4C-526
email: jdrosen@bell-labs.com