INTERNET DRAFT PIP Requirements S. Aggarwal, Microsoft
M. Day, Lotus
G. Mohr, Activerse
Expires February 1, 1999 August 7, 1998
Presence Information Protocol Requirements
draft-aggarwal-pip-reqts-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 made obsolete 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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to the
PIP discussion group at pip@iastate.edu. Discussions of the group are
archived at <URL:http://lists.fsck.com/cgi-bin/wilma/pip>.
2 Introduction
Instant Messaging has recently emerged as a new medium of
communications over the Internet. Instant messaging has spawned a
whole new category of applications that are surging in popularity. A
typical Instant Messaging application provides the following two main
areas of functionality:
(i) A means for users to find, retrieve, and be notified of changes in
the presence information (e.g. 'online' or 'offline') of other
users, and
(ii) A means for users to deliver small, simple messages instantly to
other users.
These applications currently use independent, non-standard and non-
interoperable protocols developed by various vendors, thereby
segmenting the Instant Messaging user space into disjoint islands of
communication. This severely restricts the utility of each
application. The goal of PIP is to define a standard protocol so that
Aggarwal, Day & Mohr [Page 1]
INTERNET-DRAFT PIP Requirements August 7, 1998
independently developed Instant Messaging applications can participate
in a global network across the Internet. This draft defines a minimal
set of requirements that such a Presence Information Protocol must
meet.
Although the Presence Information and Instant Messaging components of
PIP could conceivably be implemented through different protocols, there
is value to be gained by devising a single protocol that fulfils both.
Since both components have very similar requirements, there are
opportunities for one component to leverage the other. Further, the
typical Instant Messaging applications that are driving the need for
this common protocol need both capabilities, not one or the other.
It is a goal of the protocol development process to leverage existing
standards wherever possible. For example, S/MIME may be used to meet
encryption requirements.
3 Requirements common to Presence Information and Instant Messaging
3.1 The administration of presence and instant messaging is unified: in
general, an entity that makes presence information available can
receive instant messages, and vice versa.
3.2 A domain of administration for presence and instant messaging may
operate independently of another such domain; there may be a large
number of such domains.
3.3 It must be possible for entities in one domain to interoperate with
entities in another domain, without the domains having previously been
aware of each other.
3.4 All entities MUST implement some common presence format for presence
information, and for instant messages.
3.5 The common presence format MUST include a means to uniquely identify
the entity whose presence information is reported, and for an instant
message, the sender and recipient entities.
3.6 When an entity changes its presence information, any other interested
entity MUST receive the changed information rapidly - no more than a
few seconds. Similarly, the transport of instant messages MUST be
sufficiently rapid to allow for comfortable conversational exchanges
of short messages - no more than a few seconds.
3.7 Presence notifications and instant messages must be accurate the
protocol MUST provide a means to ensure that an entity receiving such
a notification or message can be confident that it has not been
corrupted or delayed. Not every notification or message need be
secured in this manner, but it must be possible to do so.
3.8 The protocol MUST provide a means so that an entity receiving a
presence notification or an instant message respectively can be
Aggarwal, Day & Mohr [Page 2]
INTERNET-DRAFT PIP Requirements August 7, 1998
confident that it represents the presence information of the entity
claimed, or sent by the sender entity claimed - that is, such messages
have not been forged. Not every notification or message need be
secured in this manner, but it must be possible to do so.
3.9 An entity MUST be able to determine and control the availability of
its presence information, and its own availability to instant messages
from others.
3.10 The protocol must provide a means of sending an instant message to a
user behind a firewall, or of determining the presence information of
another user behind a firewall. Any administrative action(s) required
to set up such firewalls must be conformant with generally accepted
firewall practices.
3.11 The protocol must meet all the stated responsiveness and feature
requirements while scaling to a global system with hundreds of
millions of users, millions of domains, and with hundreds of people on
each user's 'contact list'.
4 Additional Requirements for Presence Information
4.1 A publisher of presence information MUST be able to communicate its
changes of state, either directly or via intermediaries, to interested
entities.
4.2 The common presence format MUST include a means to access contact
information for the entity (if applicable), such as email address,
telephone number, postal address, or the like.
4.3 The common presence format MUST include a means to represent at least
the following conditions: online/offline, and available/busy/idle.
4.4 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.5 An entity MUST be able to indicate its interest in and access the
presence information of other entities, even when those other entities
are offline.
4.6 The protocol MUST provide a means for changing presence information
automatically in circumstances such as broken network connections,
which cannot be anticipated by an entity providing its presence
information.
5 Additional Requirements for Instant Messaging
5.1 An entity MUST be able to communicate an instant message, either
directly or via intermediaries such as servers, to other entities.
Aggarwal, Day & Mohr [Page 3]
INTERNET-DRAFT PIP Requirements August 7, 1998
5.2 The common message format MUST include a return address for the
receiver to reply to with an instant message.
5.3 It MUST be possible to send a MIME-encoded message through the common
message format.
5.4 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.5 The protocol MUST provide a means for an entity to send a message with
an encrypted body to another entity, so that both parties can have
confidence that no other party is able to read the body.
6 References
6.1 [Day, 1998]
M. Day, 'Requirements for Presence and Instant Messaging', draft-day-
rpim-00.txt
6.2 [Dusseault et al, 1998]
M. Calsyn, L. Dusseault, "Presence Information Protocol Requirements',
draft-dusseault-pipr-00.txt
7 Authors' Addresses
Sonu Aggarwal
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
sonuag@microsoft.com
Mark Day
Lotus Development Corporation
55 Cambridge Parkway
Cambridge, MA 02142
Mark_Day@lotus.com
Gordon Mohr
Activerse, Inc.
1301 W. 25th St Suite 500
Austin, TX 78705
gojomo@activerse.com
Aggarwal, Day & Mohr [Page 4]