INTERNET-DRAFT Vijay Saraswat Expires: August 25, 1999 Jim Malcolm Christopher Apple AT&T The Presence Protocol draft-saraswat-presenceprotocol-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 The Presence Protocol is designed to maintain presence information about a potentially large number of online users connected through various Points of Presence (PoPs), and belonging to several Federations (which are collections of uniformly administered entities). The Presence Protocol meets several of the requirements for a Presence Information Protocol [PIP-Req] in a simple, direct fashion. (Issues around security of messages are deliberately excluded from this draft.) The Presence Protocol is related to the [PIP-Demo] protocol. It differs from it in introducing a notion of Points of Presence, mediating between the Presence Server and user agents (clients) and specifys a mechanism for a user to control the dissemination of their own presence information. It is substantially simpler, doing away with leases (in favor of pings), eliminating redirections, and eliminating the dependence on an HTTP-style transport protocol. Further, it leaves for a separate protocol, the Messaging Protocol, the task of defining how Instant Messages should be Saraswat, Malcolm, Apple [Page 1] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 communicated between points of presence. 3. Introduction The Internet is rapidly evolving from just a means of accessing remote computing and information resources, and exchanging asynchronous messages to a full-fledged communications medium ("matrix") connecting people to people, computation and information, synchronously and asynchronously. The fundamental problem to be solved for the new matrix is that of maintaining information about the connectivity of people who are online ("presence information"). What is desired is a mechanism by which an endpoint A may inform another endpoint B about the current status of entities connected to A (and their receptivity to various interaction media, such as Instant Messaging, IP telephony, Multi-media sessions, etc.), and a mechanism by which an entity E may register interest in the availability and status information of another entity, F, even when F is offline. Solving this problem in an open, secure, reliable, robust, Internet-scalable way is one of the most pressing problems in application-level protocol design today. Several implemented systems (ICQ, AOL's Instant Messenger [AIM], Ding! [WhoDP]) solving some of these problems are in use today by millions of people. Very little has been officially released about ICQ protocols; substantially more information is available about Instant Messenger [AIM] (the TOC protocol) and Ding! [WhoDP]. Fundamentally, these protocols are not inter-operable, are realized within substantially different architectures, and add several additional features that complicate inter-operability. Our goal is to design a simple protocol for maintaining presence information about a collection of entities belonging to different Federations. The protocol may be used as the basis for inter-operation between different proprietary systems. The Presence Protocol is built on a 3-level architecture: we distinguish between clients (user agents running on a computer proximal to a human being), points of presence (PoP servers, e.g. a proxy server, or a network community server through which people may wish to advertise their availability), and Presence Servers (servers which maintain presence information about a large number of users, and subscriptions to that information). A PoP could cater to a single human, and may thus be Saraswat, Malcolm, Apple [Page 2] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 indistinguishable functionally from a client; typically it would cater to hundreds of entities, tens of which may be logged in at any given time. Crucially, a person may run an agent (program) on his PoP to maintain a front even if the client associated with the human is offline. This allows for a deliberate blurring of the notion of being online: for instance, the agent may initiate a cellular phone-call to the person when a message from a special person is received for him at the PoP. The Presence Protocol is used for communications between PoPs and Presence Servers. (Thus PoPs and Presence Servers are also called P-endpoints, or endpoints for short.) It may briefly be described as follows. We imagine the world of interest as consisting of a collection of entities, some of which may be present at any given time. The Presence Server maintains a database of connectivity information. An entity A, connected through an endpoint E, may subscribe through a Presence Server P to another entity B. When the status of B changes, P will notify E of the change if B's privacy specifications allow, for onward transmission to A's user agent. If P is unable to notify E (for instance, E is unreachable), P marks E as being absent, and will subsequently not attempt to deliver to E until E re- establishes its presence. In addition, P may periodically ping an end-point for current status information on the entities connected through that end-point. Such a "heartbeat" from the server ensures that presence information stored at the server is not too old. Once presence information about an entity is delivered to an endpoint, the endpoint may directly contact the entity. Protocols for exchanging instant messages, file transfer etc. between two such endpoints will be described elsewhere. Similarly, the protocol used for communication between clients and PoPs are outside the scope of this document. (Various alternatives, such as MCP or Java RMI/SMI may be used.) The actual transport protocol used to deliver Presence messages is left unspecified by this document. Requirements on the transport protocol are stated in Section 5. Note that, unlike HTTP, the Presence Protocol has deliberately been designed in such a way that delivery of messages is not acknowledged. Past designs, such as [PIP-demo], have unfortunately confounded a number of issues which have made the descriptions of the protocol quite difficult to understand. See Section 8 for more discussions. Here we adopt a layered approach to the protocol which we hope exposes the essential design decisions clearly. First Saraswat, Malcolm, Apple [Page 3] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 we provide an abstract description of our protocol, focusing on the fundamental logical components (entities), the state they maintain, and the types of interactions between them (messages they exchange). This level substantially captures the "logic" of the design (in a way that can be made precise, but that would be the purpose of another note; think of an abstract syntax for a programming language, and a structural operational semantics), without drowning itself in details of representation. The second level fleshes out some of these details ("concrete syntax"), specifying the nature of the data to be exchanged in these messages, and discusses the details of the delivery mechanisms for these messages. 4. Terminology Entity: The unit (e.g. person) on whose behalf presence information is being maintained. Each entity has a unique handle (see below); the identity of the Presence Server (see below) maintaining presence information for this entity can be determined from the handle. Handle: A well-known name for an entity. The name of the presence server managing presence information for that entity can be determined from the handle. Distinct entities have distinct handles. We assume that a PoP can locate an entity connected to it, given its handle. Typical example: pp://www.intercom.att.com/TyrantRana Endpoint: A Presence Server or a PoP. Client: A computational process directly interacting with an entity. PoP: A point of presence for an entity. If an entity is present, it is connected to exactly one PoP. Each PoP has an address (IP address, port number) at which Presence messages may be delivered. Presence Server: A server that manages presence information for a collection of entities, subscriptions to these entities, and their privacy restrictions. Each server has an address at which Presence messages may be delivered. Saraswat, Malcolm, Apple [Page 4] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 Federation: An administered collection of entities, associated with one or more Presence Servers. The collection associated with the Federation is the union of the collections associated with its Presence Servers. Presence Information: Information such as presence status, current PoP (if any), idle time, etc. for an entity. An entity has control over the publication of its presence information. Online entity: An entity for which the Presence Server knows of a PoP. (Note that for an entity to be online means that it has a point of presence in the net at which communications can be received on its behalf.) An online entity has a sub-status of either logged-in or logged-out (see below). Logged-in entity: An entity is said to be logged-in when it is online and when a client, representing a proximal human being or a user agent, is connected to the PoP. Logged-out entity: An entity is said to be logged-out when it is online but no client is connected to the PoP. Offline entity: An entity for which the Presence Server does not indicate a PoP. To mark an entity offline is to erase its PoP information in the Presence Server. Available presence status: An entity will have its presence status reported as available, subject to privacy specification, when it is logged-in. Unavailable presence status: An entity that is known to the presence server will have its presence status reported as unavailable any time it does not meet the conditions for having its presence status reported as available. Subscription: A statement by an entity of interest in the presence information of another entity. Subscriptions persist until they are explicitly rescinded. Privacy: A statement made by an entity to permit or deny its presence status to one or more specified entities or to Saraswat, Malcolm, Apple [Page 5] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 non-specified entities. Privacy may be stated as invisible, in which case its presence status, if reported, will always be unavailable, or visible, in which case its actual presence status, available or unavailable, will be reported. Privacy specifications persist until they are explicitly rescinded. 5. Assumptions 5.1 The Transport layer makes available on-demand, symmetric, reliable, non-duplicating endpoint-to-endpoint delivery of messages. Symmetricity means that if endpoint A can deliver messages to B, B may deliver messages to A. The Transport layer may accomplish this in various ways. For instance one-way firewalls may be penetrated by long-lived (bidirectional) TCP connections. 5.2 Presence Servers and PoPs are stable (long-lived). Client connectivity to PoPs may disappear unpredictably. This document specifically does not consider issues related to the authentication and security of transmitted messages. 6. Abstract Protocol Specification In this section we describe the protocol in abstract terms, without committing, for instance, to a concrete wire representation or a concrete transport protocol. These issues are discussed further in Section 7. For the moment we abstract the transport layer by assuming that endpoints have on-demand point-to-point connectivity which can be used to deliver a sequence of messages without loss or duplication. The Presence Protocol is concerned with two kinds of endpoints (PoPs and Presence Servers) and messages exchanged between them. In the abstract, a message is to be thought of as consisting of a name and a (possibly empty) set of named fields. We shall use the syntax to denote a message with name N and k named fields. An endpoint is assumed to be always ready to accept a connection from another endpoint and receive one or more messages. Saraswat, Malcolm, Apple [Page 6] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 Without specifying a mechanism to ensure this, we assume that messages are generated by PoPs only on behalf of entities connected to the PoP, and in response to activities triggered by the entity. 6.1 PoP -> Presence Server messages 6.1.1 Assert - Form 1 :endpoint
:data > An message is sent by a PoP whenever the presence information associated with an entity changes (e.g., login, change of status data, etc.). The message names the entity whose presence information is being asserted. The endpoint and data information indicate the current status of the entity. (The current presence state, and not the delta, is sent.) This form of the assert message is sent to indicate the initial logged-in status, to refresh that status in response to a heartbeat () message, and to indicate a change in the data. The receipt of such a message at the Presence Server causes a change in the presence information associated with that entity at the server. The initial logged-in message and changes in the status data will generate messages (see below) to subscribed entities, subject to the privacy specification of the asserting entity. Subsequent, messages in response to a message may not. The data is stored by the Presence Server and included in the data portion of a sent in response to a or a (see below). 6.1.2 Assert - Form 2 > When this form of the is received, the Presence Server will mark the entity as logged-out. The receipt of such a message at the Presence Server causes a change in the presence information associated with that entity at the server. Such a change will generate messages (see below) to subscribed entities, subject to the privacy specification of the asserting entity. 6.1.3 Fetch :requestor > A request to notify the requestor of the presence information of the target. The receipt of such a message causes the Presence Server to Saraswat, Malcolm, Apple [Page 7] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 evaluate this request in the light of the privacy specification associated with the requestor by the target. If the request can be honored, a message is sent back (see below) specifying a presence status of available. (Note that changes in the privacy specification of the requestor by the target may cause a subsequent identical message to be honored.) 6.1.4 Subscribe :requestor > A request to record a subscription for the target by the requestor. Subscriptions persist until the Presence Server receives an message (see below), even if the requestor goes offline. The receipt of such a message causes a change in the subscription information in the server. This may trigger a message to the requestor, subject to the privacy specification of the target. 6.1.5 Unsubscribe :requestor > The receipt of such a message causes a change in the subscription information in the server. 6.1.6 Permit :requestor > A directive to permit notifications of the requestor's presence information to be sent to the target entity. Presence information directives persist until the Presence Server receives an message, even if the requestor goes offline. The target may be <*>. If so, the default Privacy (the Privacy specification that applies to any entity that is not specifically referred to in a previous Permit or Deny) is set to visible. The receipt of such a message causes a change in the privacy information in the server. This request may result in one or more messages being sent to the target handle or to all entities that are subscribed to the requestor and are online, subject to specific privacy restrictions, for a target of <*>. 6.1.7 Deny :requestor > The receipt of such a message causes a change in the privacy information in the server blocking notifications of presence information of the requestor from being delivered to the target. Notifications must be sent to the target or all Saraswat, Malcolm, Apple [Page 8] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 entites that are subscribed to the requestor and are online indicating the presence of requestor as unavailable. The in the target may be <*>. If so, the default Privacy (the Privacy specification that applies to any entity that is not specifically referred to in a previous Permit or Deny) is set to invisible. 6.1.8 Inquire :subscribed> :subscription> :privacy> An inquire message requests the handles of those entities who have subscribed to the requestor, the handles of the entities to whom the requestor has subscribed, and the handles and privacy specification of those entities to whom the requestor has specified a Privacy. The requested information is returned in the data portion of one or more messages. 6.2 Presence Server -> PoP messages 6.2.1 Notify :endpoint
:data :requestor > A message is sent by the Presence Server to convey about a named entity at the named endpoint. A may be sent in response to a , an , or a , or when an entity subscribed to by the requestor changes presence state (becomes available or unavailable). If the attempt to contact the endpoint for the requestor B fails, then the requestor shall be marked offline. No attempt is made to deliver messages to offline entities. Because of privacy information stored with it, the Presence Server may ignore some requests, or return an unavailable status, from a PoP and honor others. Including requestor information allows the PoP to determine the requestor honored by the Presence Server. 6.2.2 Ping > A message is sent by the presence server to a PoP to determine whether the named entity is present. If message delivery succeeds, and no for that entity is received within a pre-determined amount of time, the entity is marked as offline. If message delivery fails, the entity Saraswat, Malcolm, Apple [Page 9] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 is marked as offline. The rate at which a Presence Server may choose to send messages is entirely up to the server. 7. Message Representation and Transport Protocols A message may be represented in ASCII using MCP "simple message" syntax (with no multi-line values, #$# prefixes, or authentication codes) [MCP]. XML should also be considered. As an extension, a scheme should be considered for associating public and private keys with entities (public key is maintained at the Presence Server, and private key at the PoP for the entity) and using them for authentication. The message traffic described above can be carried over many different transport protocols. For instance, short-lived HTTP hits may be used to deliver a single message; in this case each message field would be translated into an HTTP header. (This option is not recommended.) Alternatively, an endpoint may deliver messages to another endpoint by opening a TCP connection, sending messages, and then closing the connection. Yet another alternative would be to use SMTP-style bidirectional delivery of messages (as above, but checking to see if there are any messages to be received in the other direction). 8. Discussion Several comments with respect to the PIP-Demo protocol are appropriate. The Presence Protocol has very much been influenced by the PIP-Demo protocol, and was motivated by a desire to peel away its conflation of levels and concerns (the merging of Presence information and Instant messaging, the use of HTTP for delivery etc.) and to fundamentally account for the notion of PoPs. First, PoPs allow for the notion of a stable, user- controlled presence in the Net that may be accessible even when the user is not connected to the net, and that may receive and process messages on behalf of the user. Second, they also allow for a natural notion of aggregation -- a PoP may serve as the point of presence for several entities; a subscription by just one of these entities may serve as a subscription for all of them (modulo privacy concerns), thereby substantially reducing network traffic. Saraswat, Malcolm, Apple [Page 10] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 Third, Instant Messaging traffic goes PoP to PoP, bypassing the Presence Server. This has good scaling properties. It also solves the fundamental "missing IMs" problem. (A person may choose to set up his PoP so that the last n messages are always recorded. Thus when he drives home from work, without shutting down his client at work, he can retrieve IMs that might have been displayed on his machine at work by connecting up from his client at home. Without the intermediary PoP there is no easy way by which he can see the IMs displayed on his office machine while he is at home.) Fourth, PoPs introduce a level of indirection between clients that is useful for maintaining privacy. It is not unreasonable to assume that PoPs will be run by experienced administrators, whereas clients may be much more vulnerable to attack. The Presence Protocol does not reveal client information to other clients, thus protecting the weak link. Finally, because the PoP for a user is expected to change relatively infrequently --- though the user may "login" and "logout" of the PoP quite frequently --- the need for "redirection" does not arise. We have also discovered that the notion of establishing a lease for subscriptions is rather complex to work with in practice. Typically, a person has a stable, slowly varying list of subscriptions. It seems best to store this list at the Presence server, rather than at the PoP, or, worse at the client. Thus the need for selecting arbitrary lease intervals, and for initiating lease-maintenance network traffic is avoided. The failure to deliver a notification to an entity instantly marks it as offline, thus choking off any further attempts to deliver messages. Pings are used by the server (in the absence of any entity-generated messages) to keep track of whether a PoP is reachable or not. The problem of the PoP engaging in some heartbeat mechanism with its clients is decoupled from the problem of PoP/Presence Server heartbeat. (A PoP may well keep an open TCP connection to its client, and thus may have a different way of determining the accuracy of its presence information.) The abstract protocol presented for discussion is a minimal set of primitives embodying the core design decisions necessary to implement a presence system. * Each message describes a single action. * Each message specifies the entity or entities involved in the action. * Only those actions require for the presence service are specified. A number of additional design decisions are need to be Saraswat, Malcolm, Apple [Page 11] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 specified before a realizable system may be implemented: * What is the format and content of . * When may a message be sent; how to balance the freshness of the presence information versus specifying an overly "chatty" protocol. * How should errors be reported; is there a need for confirmation messages. In future work we wish to examine further the assumptions placed on the transport protocol and determine if they can be weakened (so that, for instance, UDP may be used), perhaps at the cost of adding some extra information to messages. 9. Acknowledgements The authors acknowledge gratefully being influenced by many colleagues on the PIP mailing list and within the Intercom and Matrix projects at AT&T. We specifically wish to acknowledge Fernando Pereira for detailed comments. 10. References [AIM] "Welcome to TiK -- The AOL Instant Messenger Tcl/Tk 8.0 Client", http://www.aim.aol.com/tik [MCP] "The MUD Client Protocol (MCP)", http://www.moo.mud.org/mcp [RVP] M. Calsyn, L. Dusseault, G. Mohr, "RVP: A Presence Notification Protocol", draft-calsyn-rvp-01.txt [WhoDP] G. Mohr, "WhoDP: Widely Hosted Object Data Protocol", draft-mohr-whodp-00.txt [PIP-Demo] G. Mohr, S. Aggarwal, M. Day, A. Houri, Y. Kohda, D. Marvit, "PIP-DEMO: An Interoperable Presence Information Protocol", draft-mohr-pip-pipdemo-00.txt [PIP-Req] S. Aggarwal, M. Day, G. Mohr, "Presence Information Protocol Requirements", draft-aggarwal-pip-reqts-00.txt Saraswat, Malcolm, Apple [Page 12] INTERNET DRAFT PRESENCE PROTOCOL FEBRUARY 26, 1999 11. Author Addresses Vijay Saraswat AT&T Labs Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932 vj@research.att.com Jim Malcolm AT&T Labs Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932 jim@control.att.com Christopher Apple AT&T Labs Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932 capple@control.att.com Saraswat, Malcolm, Apple [Page 13]