[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                                Mark Day
Expires: September 13, 1998              Lotus Development Corporation


              Requirements for Presence and Instant Messaging

                      draft-day-rpim-00.txt


1. Status of this Memo

This document is an Internet-Draft.  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."

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).


2. Abstract

This document is an alternative approach to defining the requirements
for a presence information protocol.  It may be usefully compared and
contrasted with "Presence Information Protocol Requirements" by Lisa
Dusseault, draft-dusseault-pipr-00.txt.  Although worthy in many
respects, that document includes numerous desiderata, design
considerations, and implementation concerns.  This document attempts
to define only requirements, and a minimal set of requirements at
that. In addition, this document treats "presence" and "instant
messaging" as distinct entities for the purpose of defining
requirements. We leave open the possibility of a single protocol
fulfilling both sets of requirements, without requiring it.

3. Introduction

A presence information protocol provides a means for clients to find,
retrieve, and be notified of changes in the presence information of
others. Presence information is information exposed by a client to
indicate the presence or availability of a person or resource.

An instant messaging protocol provides a means for clients to deliver
small, simple messages to other clients. Instant messaging is similar
to email, but instant messages are not stored for later
delivery. Instant messages are intended only as a lightweight
conversation and rendezvous mechanisms for persons or systems,
exchanging information that may be used to set up heavier-weight
mechanisms for conversation or sharing.

Presence information and instant messaging are distinct but
interdependent. When user A knows that user B is available, it is
useful for A to be able to initiate a conversation with B, building on
the information and service already shared by both
parties. Correspondingly, when A is preparing to send a message to B,
it is useful to know whether B is present and able to receive an
instant message. If B is not available, A may not send a message, may
send the message via email, or may compose a different message via a
different medium.

This document describes the requirements for a presence protocol and
an instant messaging protocol. Although these are described as
requirements on separate protocols, there is no requirement that they
be separate. The requirements may be satisfied by a single combined
protocol.

4. Requirements for a Presence Information Protocol

4.1 A client MUST be able to communicate its presence information,
either directly or via intermediaries such as servers, to other
clients.

4.2 All clients MUST implement some common presence format for
presence information.

4.3 The common presence format MUST include a means to represent an
individual name (a personal name in the case of a person), and
organizational or other disambiguating information.

4.4 The common presence format MUST include a means to represent
contact information, such as email address, telephone number, postal
address, or the like.

4.5 The common presence format MUST include a means to represent at
least the following conditions: active, inactive, unavailable, do not
disturb.

4.6 There MUST be a means of extending the common presence format to
represent additional information not included in the common format,
without undermining or rendering invalid the fields of the common
format.

4.7 A client MUST be able to indicate its interest in the presence
information of other clients, even when those other clients are not
available or not reachable.

4.8 When a client changes its presence information, and another client
has indicated interest in the presence information of that client, the
interested client MUST receive the changed information rapidly enough
that the delay is not objectionable. For most applications, this
implies a delay of no more than a few seconds.

4.9 The protocol MUST provide a means so that a client receiving an
update can be confident that it represents the correct presence
information (that is, it has not been corrupted or delayed).

4.10 The protocol MUST provide a means so that a client receiving an
update can be confident that it represents the presence information of
the client claimed (that is, it has not been forged).

4.11 The protocol MUST provide a means for changing presence
information automatically in circumstances such as broken network
connections, which cannot be anticipated by a client providing its
presence information.

5. Requirements for an Instant Messaging Protocol

5.1 A client MUST be able to communicate an instant message, either
directly or via intermediaries such as servers, to other clients.

5.2 All clients MUST implement some common message format for instant
messages.

5.3 The common message format MUST include a means to represent a
recipient's individual name (a personal name in the case of a person),
and organizational or other disambiguating information.

5.4 The common message format MUST include enough information to allow
the receiver to send an instant message as a reply.

5.5 The common message format MUST include a MIME-encoded body.

5.6 The protocol MUST make visible to the sender whether the instant
message was successfully received. Successful receipt means only that
the message was transmitted to an entity on the receiving machine
responsible for displaying it, not that the message was actually read
by a user.

5.7 The transport of instant messages MUST be sufficiently rapid to
allow for comfortable conversational exchanges of short messages. For
most applications, this means that the time to deliver a message
can be no more than a second or two.

5.8 The protocol MUST provide a means so that a client receiving a
message can be confident that it represents the message as recently
sent (that is, it has not been corrupted or delayed).

5.9 The protocol MUST provide a means so that a client receiving a
message can be confident that it represents the message sent by the
client claimed (that is, it has not been forged).

5.10 The protocol MUST provide a means for a client to send a message
with an encrypted body to another client, so that both parties can
have confidence that no other party is able to read the body.

6. Author's Address

Mark Day
Lotus Development Corporation
55 Cambridge Parkway
Cambridge, MA 02142
USA

Mark_Day@lotus.com