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]