Re: "De facto charter" proposed text

That is because the operations that you mention are going to be specific to
a particular protocol (i.e. they do not cross administrative domain
boundaries), and thus not required for interoperation.

Thanos
---
Thanos Diacakis
Openwave Systems
[email protected]
+1-303 385 6705

----- Original Message ----- 
From: "sivaram" <[email protected]>
To: "'Mark Day'" <[email protected]>; <[email protected]>
Sent: Thursday, May 22, 2003 11:36 PM
Subject: 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]
>
>




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