RE: "De facto charter" proposed text

Thanx Thanos for replying. What u say makes sense for Ques1. For Ques2, I
assume what u are saying is that the presence info is always sent to (&
stored by) the local presence service. Watchers in other domains can
subscribe & get notified whenever the presentity's presence info changes. In
other words, presentities always talk to the presence service in the same
domain whereas watchers can talk to presence service in other administrative
domains as well.

It will definitely be useful if such info is put in the drafts (for people
who haven't been following the group's activities).

Regds,
Sivaram.

-----Original Message-----
From: Thanos Diacakis [mailto:[email protected]]
Sent: Friday, May 23, 2003 9:14 PM
To: sivaram; 'Mark Day'; [email protected]
Subject: 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]
>
>


**************************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]