Internet DRAFT - draft-aggarwal-pip-reqts

draft-aggarwal-pip-reqts






     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]