RE: "De facto charter" proposed text

As a new member of this group, the explanation below on history and current
de-facto charter is very helpful. However, I had a couple of questions, for
which I didn't receive any reply before. It will be highly helpful if any of
u could provide answers to these questions (in fact better still if it is
clarified in the CPIM and CPP drafts). The questions are:

1) While reading through CPIM doc (draft-ietf-impp-im-02), I found the
MESSAGE operation being invoked from appl (refers to SENDER of RFC2778, I
think) to the service. Why is there no invokation from service to the
instant inbox (to deliver the message) ? Is it because, we assume the inbox
is internal to the service (I thought inbox here would be part of whatever
IM s/w, a end user is having).

2) CPP doc (draft-ietf-impp-pres-02): A similar question to the above. Why
is there no operation from the presentity to the service to send the
presence info ?

The reason why I ask this is because, these docs seem to leave a part of the
model described in 2778 un-addressed. I am sure there would have been valid
reasons for this, only problem is that it doesn't seem to come out in any of
the docs.

Thanks & Regards,
Sivaram.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Mark Day
Sent: Friday, May 23, 2003 4:25 AM
To: IMPP Working Group
Subject: "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]



**************************Disclaimer************************************

Information contained in this E-MAIL being proprietary to Wipro Limited is 
'privileged' and 'confidential' and intended for use only by the individual
 or entity to which it is addressed. You are notified that any use, copying 
or dissemination of the information contained in the E-MAIL in any manner 
whatsoever is strictly prohibited.

***************************************************************************



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