Internet DRAFT - draft-day-atkins-impp-defacto

draft-day-atkins-impp-defacto



                                                      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