Skip to main content

Proposed Design Decisions for IMPP

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Mark Day , Gordon Mohr , Sonu Aggarwal , Greg Hudson
Last updated 1999-10-04
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


As of this writing, the IMPP working group has largely reached consensus on the requirements for IMPP [Reqts]. In addition, Hudson [Issues] has catalogued a set of design issues discussed on the mailing list. This document proposes a starting point for further discussions about the design of the Instant Messaging and Presence Protocol (IMPP). It is not a fully-specified protocol, but a summary of design decisions on which the authors were able to reach agreement during two full days of discussion. Our discussions drew on knowledge of operational and architectural aspects of Activerse Ding!, Lotus Sametime, Microsoft Exchange instant messaging, MSN Messenger, and Zephyr, among other diverse, widely-deployed systems supporting presence and/or instant messaging. We believe that the issues on which we reached agreement are issues on which the working group as a whole should be able to quickly reach rough consensus. We hope that the working group will be able to adopt these decisions as the basis for further work on designing IMPP; of course, we recognize the possibility that strong technical arguments not hitherto considered may cause the group to arrive at different decisions in some instances. We also identified some areas, primarily related to security, in which we were lacking enough information or experience to make a solid recommendation. We draw the working group's attention to these issues in the hope that others can contribute. Although we have treated presence and instant messaging in the same document, we believe that these design decisions allow implementors to offer either service independently of the other.


Mark Day
Gordon Mohr
Sonu Aggarwal
Greg Hudson

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)