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
<N :field1 val1 :field2 val2 ... :fieldk valk>
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
<Assert :entity <handle> :endpoint <address> :data
<data>>
An <Assert> 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 (<Ping>) 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 <Notify> messages (see below) to subscribed
entities, subject to the privacy specification of the
asserting entity. Subsequent, <Assert> messages in response
to a <Ping> message may not.
The data is stored by the Presence Server and included in
the data portion of a <Notify> sent in response to a
<Subscription> or a <Fetch> (see below).
6.1.2 Assert - Form 2
<Assert :entity <handle>>
When this form of the <Assert> 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 <Notify> messages (see
below) to subscribed entities, subject to the privacy
specification of the asserting entity.
6.1.3 Fetch
<Fetch :target <handle> :requestor <handle>>
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 <Notify> 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
<Subscribe :target <handle> :requestor <handle>>
A request to record a subscription for the target by the
requestor. Subscriptions persist until the Presence Server
receives an <Unsubscribe> 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
<Notify> message to the requestor, subject to the privacy
specification of the target.
6.1.5 Unsubscribe
<Unsubscribe :target <handle> :requestor <handle>>
The receipt of such a message causes a change in the
subscription information in the server.
6.1.6 Permit
<Permit :target <handle> :requestor <handle>>
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 <Deny> message, even if the requestor
goes offline. The target <handle> 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 <Notify> 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
<Deny :target <handle> :requestor <handle>>
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 <handle> 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
<Inquire :requestor <handle> :subscribed>
<Inquire :requestor <handle> :subscription>
<Inquire :requestor <handle> :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
<Notify> messages.
6.2 Presence Server -> PoP messages
6.2.1 Notify
<Notify :entity <handle> :endpoint <address> :data
<data> :requestor <handle>>
A <Notify> message is sent by the Presence Server to convey
<data> about a named entity at the named endpoint. A
<Notify> may be sent in response to a <Fetch>, an <Inquire>,
or a <Subscribe>, 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 <Notify> messages to offline
entities.
Because of privacy information stored with it, the Presence
Server may ignore some <Fetch> 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
<Ping :entity <handle>>
A <Ping> message is sent by the presence server to a PoP to
determine whether the named entity is present. If message
delivery succeeds, and no <Assert> 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
<Ping> 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 <data>.
* When may a <Notify> 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]