Re: Requests on "de facto charter" discussion

Yes indeed. If we look at what the purpose for this de facto charter is, the
question is "How *did* we decide which requirements ..."
instead of "How do we decide which requirements ...".

I think we should add an intro to this "de facto charter" explaining its
purpose, as it is not really a "charter".  Maybe even we shouldn't call it
that, but call it a "WG history" or something similar.

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

----- Original Message ----- 
From: "Peterson, Jon" <[email protected]>
To: "'Thanos Diacakis'" <[email protected]>; "'Mark Day'"
<[email protected]>; "IMPP Working Group" <[email protected]>
Sent: Tuesday, May 27, 2003 1:05 PM
Subject: RE: Requests on "de facto charter" discussion


>
> Relevance to our charter is, I think, the only matter under consideration
> here. I thought we were trying to document how we did what we have done,
not
> figure out how we might have done things differently if we were going to
> start all over. These documents all went through last call in this WG, and
I
> don't remember you or anyone else agonizing then over whether or not the
> subscription authorization requirements of RFC2779 had been met. We are no
> longer at a stage where we are figuring out what requirements these
> documents "should meet".
>
> We had lengthy discussions in this group, instigated by John Ramsdell,
about
> the possibility of creating an end-to-end format for subscription requests
> that would meet the 5.1 requirements (right after Yokohama). The
> overwhelming consensus of the group was that these capabilities should be
> deferred to the using protocol, rather than instantiated in some sort of
> common format we design here. The primary argument, actually, for
deferring
> this was that there were no end-to-end security properties required for
> subscription requests in RFC2779 - RFC2779 did not require a common and
> interoperable format for subscription requests. There was no work that
> needed to be done to facilitate interoperability of using protocols with
> respect to this requirement - which was the focus of IMPP after the CPIM
> reorientation.
>
> Jon Peterson
> NeuStar, Inc.
>
> > -----Original Message-----
> > From: Thanos Diacakis [mailto:[email protected]]
> > Sent: Tuesday, May 27, 2003 10:12 AM
> > To: Peterson, Jon; 'Mark Day'; IMPP Working Group
> > Subject: Re: Requests on "de facto charter" discussion
> >
> >
> > The fact that the requirements that the IMPP documents do not
> > meet, are met
> > elsewhere (e.g. SIMPLE) is somewhat irrelevant to our charter.
> >
> > The point is:
> >
> > - How do we decide which requirements the IMPP WG documents
> > should meet, and
> > which should the specific protocols implement?
> >
> > Currently, this was done fairly arbitrarily.
> >
> > A few requirements come to mind that we haven't dealt with:
> >
> > - Subscription authentication (a few reqts on that in section
> > 5.1 of 2779)
> > - Subscription cancellation notification (5.1.9)
> > - Subscription status (5.1.10)
> >
> > IMHO, where things are right now with the status of various
> > related WGs, our
> > whole approach needs rethinking, and this should be done
> > separately for
> > Presence and separately for IM.
> >
> > Thanos
> > ---
> > Thanos Diacakis
> > Openwave Systems
> > [email protected]
> > +1-303 385 6705
> >
> > ----- Original Message ----- 
> > From: "Peterson, Jon" <[email protected]>
> > To: "'Mark Day'" <[email protected]>; "IMPP Working Group"
> > <[email protected]>
> > Sent: Monday, May 26, 2003 3:48 PM
> > Subject: RE: Requests on "de facto charter" discussion
> >
> >
> > >
> > > Just to clarify my perspective on this, I didn't mean to
> > suggest that
> > > CPIM/CPP only selectively satisfies the requirements of
> > RFC2779 - merely
> > > that some requirements are requirements on the 'common
> > formats', and some
> > > requirements are requirements on the using protocols.
> > Obviously, MSGFMT
> > > should meet the requirements in RFC2779 section 4.1, which are
> > specifically
> > > tailored for a common format. The point is that other
> > requirements are not
> > > met by any feature of the CPIM/CPP common format work -
> > instead, they have
> > > to be met by a using protocol that instantiates the
> > 'abstract' protocols
> > > described in the core CPIM/CPP documents. Subscription
> > authentication is a
> > > good example of a requirement in RFC2779 that has no corresponding
> > mechanism
> > > in CPIM/CPP. We hadn't decided in IMPP that this
> > requirement was wrong or
> > > unfulfillable or something - instead, IMPP has just passed
> > the buck to the
> > > using protocols (APEX, SIMPLE, etc) to meet this
> > requirement, as was the
> > > case with many requirements. CPIM and CPP are not,
> > themselves, instant
> > > messaging or presence 'protocols'.
> > >
> > > I am aware of no specific requirements from RFC2779 that we
> > have rejected.
> > I
> > > don't mind adding the word "minimal" per request 2 below.
> > As for request
> > 3,
> > > I'm not sure I would favor that precise wording. Perhaps
> > something more
> > > like: "This lack of an official direction encouraged
> > participants to work
> > > from differing assumptions and goals, which fueled
> > recurring fundamental
> > > disagreements and hampered consensus."
> > >
> > > Jon Peterson
> > > NeuStar, Inc.
> > >
> > > > -----Original Message-----
> > > > From: Mark Day [mailto:[email protected]]
> > > > Sent: Monday, May 26, 2003 10:55 AM
> > > > To: IMPP Working Group
> > > > Subject: Requests on "de facto charter" discussion
> > > >
> > > >
> > > > I am finding the responses to the proposed de facto charter
> > > > interesting.
> > > >
> > > > I do have a number of specific requests below.
> > > >
> > > > I was intrigued by the idea (apparently shared by several
> > > > people) that the
> > > > WG had picked and chosen which 2779  requirements were
> > > > relevant.  I know we
> > > > have had areas where various folks have claimed that some
> > > > requirement isn't
> > > > met by our current docs, but I thought that those were
> > > > primarily individual
> > > > differences of opinion or interpretation.  I couldn't
> > > > remember any places
> > > > where the WG said that it could ignore some part of 2779.
> > > >
> > > > If there are areas we could identify where the WG chose not
> > > > to be bound by
> > > > 2779, we certainly need to be explicit about those and
> > > > explain them. So
> > > > here's my first request:
> > > >
> > > > REQUEST 1 is to send me (and the WG) any examples of those
> > > > areas. I'm asking
> > > > for areas where the WG decided that it was OK not to meet the
> > > > requirement or
> > > > that some requirement didn't make any sense.
> > > >
> > > > Next, I am torn between a desire to accurately reflect
> > > > Marshall's concerns
> > > > and an unwillingness to get caught between duelling
> > memories among the
> > > > people who participated in the Group of Nine.  I have already
> > > > spent too much
> > > > time ducking that crossfire. ;-)
> > > >
> > > > I'd propose adding the word "minimal" and hope that Marshall
> > > > might find this
> > > > less misleading:
> > > >
> > > > "The goal was to define some common information that
> > would allow some
> > > > minimal kind of interoperability of the different
> > protocols, even if a
> > > > single protocol was
> > > > not possible."
> > > >
> > > > I think this might also help with Adrian's suggestion that we
> > > > capture more
> > > > of the "minimality discipline" we followed wrt what's in
> > the formats,
> > > > although perhaps that also needs to be identified explicitly.
> > > >
> > > > I'd also be happy to substitute a more-abstract,
> > less-loaded word than
> > > > "interoperability" or "gatewaying" but I can't come up with
> > > > one.  "Some kind
> > > > of interoperability" was intended to be fuzzy enough to cover
> > > > gatewaying.
> > > > When I use words like "interaction" or "communication" instead of
> > > > "interoperability", it seems to have lost all content.
> > > >
> > > > So REQUEST 2 is to offer comments about this proposed change.
> > > >
> > > > Finally, I think the concerns about legitimacy and technical
> > > > soundness will
> > > > already be on everyone's minds, but I'd be happy to
> > > > underscore the concerns
> > > > about those areas if the current wording isn't doing it
> > > > sufficiently. We
> > > > could add a sentence after the one about the charter not
> > > > being updated to
> > > > underscore the legitimacy issue.  For example, something like
> > > > "This failure
> > > > meant that it was difficult to judge the soundness of
> > > > subsequent decisions.
> > > > As a result, some parts of the community came to believe
> > that IMPP was
> > > > making arbitrary choices and not producing sound results."
> > > >
> > > > REQUEST 3 is to offer comments about this proposed change.
> > > >
> > > > Thanks in advance,
> > > >
> > > > --Mark
> > > >
> > > >
> > > >
> > > >
> > > >   [reminder: [email protected] for non-technical
> > > > discussions, please]
> > > >
> > > >
> > >
> > >
> > >
> > >   [reminder: [email protected] for non-technical
> > discussions, please]
> > >
> > >
> >
>




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