Mark Day Cisco Derek Atkins IHTFP Consulting IMPP Working Group History and De Facto Charter draft-day-atkins-impp-defacto-00 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 10, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This is a "de facto IMPP charter" to accompany the IMPP submissions to the IESG. Such an arrangement is not ordinarily part of the IETF process, but appears to be the most effective means of providing necessary context to the IESG as it considers the IMPP documents. The first part of this document describes the circumstances that have led to this unusual de facto charter. The second part describes the IMPP charter as it has been understood by the current chairs. 1. History IMPP was originally chartered to "eventually define protocols and data formats necessary to build an internet-scale end-user presence awareness, notification and instant messaging system." The WG successfully delivered RFCs 2778 and 2779, then solicited proposals for protocol designs meeting the requirements described there. The design contest had a number of entries and an unanticipated effect: the proposals split the WG into three groups. Each supported a different approach to developing IMPP. RFCs 2778 and 2779 did not in themselves provide a basis for declaring one of these proposals superior. The ADs appointed a design team dubbed the "Group of Nine" or simply "The Nine" consisting of 3 persons from each of the three camps, and tasked them with determining what the core mechanisms were that they could all agree on. The goal was to define some common information that would allow some minimal kind of interoperability of the different protocols, even if a single protocol was not possible. The Nine outlined a structure of "Common Presence and Instant Messaging" (CPIM) operations and two common formats, one for instant messages and one for presence information. Subsequently, the IESG chartered three new WGs as "children of IMPP": APEX, PRIM, and SIMPLE. Included in each child group's charter was a requirement that its protocol must be CPIM-compliant. This requirement was also placed on XMPP when it became a chartered working group. A crucial omission at this stage was that IMPP's charter was not updated to reflect the changed circumstances. This lack of an official direction led participants to work from differing assumptions and goals, which fueled recurring fundamental disagreements and hampered consensus. 2. Current de facto charter IMPP has developed requirements for instant messaging and presence in RFCs 2778 and 2779. Its current charter is to devise: (1) a common extensible instant message format (the MIME type message/cpim, sometimes referred to as MSGFMT); (2) a common extensible presence information format (the MIME type application/pidf+xml, sometimes referred to as PIDF); (3) an abstract operational profile for protocols that implement instant messaging using MSGFMT (which profile is somewhat confusingly also called CPIM); and (4) an abstract operational profile for protocols that implement presence using PIDF (which profile is called CPP). IMPP does not produce protocols that carry these formats, but it does place requirements on the protocols produced by other groups. Other protocols could also be designed from scratch or adapted from existing protocols to become IMPP-compliant. An IMPP-compliant instant messaging system would have to (at least) carry MSGFMT messages, conform to the CPIM profile, and otherwise meet the common and instant-messaging requirements of RFCs 2778 and 2779. A IMPP-compliant presence system would have to (at least) carry PIDF messages, conform to the CPP profile, and otherwise meet the common and presence requirements of RFCs 2778 and 2779. 3. Contact Information for Authors Mark Stuart Day Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 Email: mday@alum.mit.edu Derek Atkins IHTFP Consulting 6 Farragut Ave Somerville, MA 02144 Email: derek@ihtfp.com