A Model for Presence and Instant Messaging
RFC 2778
Document | Type |
RFC - Informational
(February 2000; No errata)
Was draft-ietf-impp-model (impp WG)
|
|
---|---|---|---|
Authors | Hiroyasu Sugano , Mark Day , Jonathan Rosenberg | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized 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 | | | +---------------------------+ ^ | | | | v +------------+ +------------+Show full document text