A Model for Presence and Instant Messaging
RFC 2778
| Document | Type |
RFC - Informational
(February 2000; No errata)
Was draft-ietf-impp-model (impp WG)
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2778 (Informational) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
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 |
| |
Show full document text