De facto IMPP charter (Retreat Agenda Topic)

[Ted Hardie <hardie@qualcomm.com>]

Hi,
	Both at the last IETF and after, there have been a number of discussion
surrounding the IM-related working groups that have struck me as
rooted in a conflicting set of assumptions about the work that had been
taken on.  Peering back into history a bit, I think part of that problem
is quite simply that the IMPP working group was not re-chartered
when the whole IMPP/APEX/SIMPLE/PRIM split took place.  Since
then, different communities seem to me to have evolved slightly 
different
views, especially of the work of IMPP.
	As a first step toward working that out, I asked the chairs of IMPP
to give me their view of the de facto charter of IMPP.  Below is that 
view, as
well as a take on the history from their perspective.  I'd like us to 
put this
as a topic for the retreat agenda, so we can develop a consensus view
of how we will evaluate the IMPP documents when they come our way.
				regards,
					Ted Hardie


Begin forwarded message:

> From: "Mark Day" <markday@cisco.com>
> Date: Tue Apr 15, 2003  6:26:55 AM US/Pacific
> To: "Ted Hardie" <hardie@qualcomm.com>
> Cc: "Derek Atkins" <warlord@mit.edu>
> Subject: De facto IMPP charter
>
> 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.