Re: "De facto charter" proposed text

Jon,


PJ> Just as a general comment on this whole line of inquiry, I don't think CPIM
PJ> is supposed to instantiate the RFC2778/RFC2779 architecture/requirements in
PJ> their entirety.

As the working group archives over the last couple of years will show,
2778/2779 "requirements" were consistently cited as the reason one or
another feature had to be included in CPIM.

Therefore, failure to satisfy those requirements raises a very real
specifications. When 2778/2779 was cited, there were no discussions
about satisfying requirements selectively. Had there been, there would
have been a question about the basis for choosing which requirements to
satisfy.

By way of confirming the original this original intent for CPIM, note
early text from a CPIM draft: "The CPIM profile meets the requirements
specified in RFC 2779 using a minimalist approach allowing
interoperation of a wide range of IM and Presence systems."

Any change in this goal happened long after the work of The Nine.


PJ> It is a set of tools that can be used by a protocol (like

The key phrase in the specifications is "common semantics and data
formats".  That is rather more than just "a set of tools".


PJ> Consequently, I don't think we're under any obligation to show a one-to-one
PJ> correspondence between RFC2779 requirements and CPIM features. CPIM is not
PJ> itself an instant messaging protocol - it is an abstract model for such
PJ> protocols and a pair of formats that might be carried by such protocols.

a specification that provides detailed, end-to-end syntax and semantics
is rather more than "an abstract model".


PJ> Finally, I would comment that if there is doubt in our minds as to whether
PJ> or not CPIM exactly satisfies the requirements of RFC2779, then satisfaction
PJ> of those requirements could hardly be part of the "de facto" charter,

Given that satisfaction of 2779 was constantly cited as a requirement
during the working group's efforts, then having the charter call for
satisfying those requirements would be merely be an accurate recording
of how the working group actually chose to behave.


d/
--
 Dave Crocker <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>




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