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