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 . 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]