@techreport{day-impp-basis-00, number = {draft-day-impp-basis-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-day-impp-basis/00/}, author = {Mark Day and Gordon Mohr and Sonu Aggarwal and Greg Hudson}, title = {{Proposed Design Decisions for IMPP}}, pagetotal = 0, year = 1999, month = oct, day = 4, abstract = {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.}, }