"De facto charter" proposed text

We now have our various documents ready to go to the IESG.  However, our AD
(Ted Hardie) and others have noted that the current IMPP charter is not a
very useful guide to understanding or evaluating the documents, since it has
not been updated in the course of IMPP's long strange trip.

Derek and I produced some text a few weeks ago that we call the "de facto
charter" since it summarizes what we have been using as a basis for chairing
the group. Little in it is likely to be surprising for people who've been
following the group.  But the text is the first time that we've tried to
really write these various principles and goals down.

We're currently assuming that we will send some version of a "de facto
charter" to the IESG as a supplement or replacement for our existing
charter.  We'd like to hear from WG members if this text seems mismatched to
what you think the group has been trying to accomplish.

Note that this is a slightly different question from whether the group
*should* be trying to do something different.  That can be an interesting
discussion, but one that will distract us from getting the documents and
sensible evaluation criteria to the IESG.  We'd like to keep comments
focused on whether we've accurately captured what the WG rough consensus
direction has been.

Text follows and has been submitted as draft-day-atkins-impp-defacto-00.txt

Yr humble co-chairs,

Mark and Derek

------------------------

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 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.

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.



  [reminder: [email protected] for non-technical discussions, please]