[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evaluation: draft-ietf-impp-im - Common Profile for Instant Messaging (CPIM)



Hi Ted,

I have some comments/questions on this document set, although I
am not sure that they warrant a "discuss":

draft-ietf-impp-im-03.txt:

The abstract and first section both say that "Today...little
interperability...has been achieved." While that's probably
true _today_, is that really something that we want to say at
the top of a standard that will hopefully live for many years?

draft-ietf-impp-cpim-msgfmt-08.txt:

The TOC in this document doesn't have page numbers, so I am not
sure why it has been included.  Would the RFC editor fix
something like this?

draft-ietf-impp-cpim-pidf-08.txt:

This doesn't seem like a well-formed reference:

[MIME] Multipurpose Internet Mail Extensions. See RFC 2045, RFC 2046,
RFC 2047, RFC 2048, and RFC 2049.

And, the indicated RFCs don't have references in this document.

draft-ietf-impp-pres-03.txt:

This document also talks about the status "today". This seems unwise
in a standard that will hopefully live for a long time.







At 02:03 PM 7/24/2003 -0400, IESG Secretary wrote:

Last Call to expire on: 2003-06-27

Please return the full line with your position.

Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ ] [ ] [ ]
Steve Bellovin [ ] [ ] [ ] [ ]
Randy Bush [ ] [ ] [ ] [ ]
Bill Fenner [ ] [ ] [ ] [ ]
Ned Freed [ ] [ ] [ ] [ ]
Ted Hardie [ ] [ ] [ ] [ ]
Russ Housley [ ] [ ] [ ] [ ]
Allison Mankin [ ] [ ] [ ] [ ]
Thomas Narten [ ] [ ] [ ] [ ]
Jon Peterson [ ] [ ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ ] [ ]
Bert Wijnen [ ] [ ] [ ] [ ]
Alex Zinin [ ] [ ] [ ] [ ]

2/3 (9) Yes or No-Objection opinions needed to pass.

DISCUSSES AND COMMENTS:
======================



^L
---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: "RFC Editor" <rfc-editor@isi.edu>,
"Internet Architecture Board" <iab@iab.org>, <impp@iastate.edu>
Subject: Protocol Action: 'Common Profile for Instant Messaging
(CPIM)' to a Proposed Standard
------------------------

The IESG has approved the Internet-Drafts 'Common Profile for Instant
Messaging (CPIM)' <draft-ietf-impp-im-03.txt>, 'Address Resolution for
Instant Messaging and Presence' <draft-ietf-impp-srv-03.txt>, 'Common
Presence and Instant Messaging: Message Format'
<draft-ietf-impp-cpim-msgfmt-08.txt>, 'Common Profile for Presence
(CPP)' <draft-ietf-impp-pres-03.txt>, and 'Presence Information Data
Format (PIDF)' <draft-ietf-impp-cpim-pidf-08.txt>, each as
Proposed Standard.

These documents are the product of the Instant Messaging and Presence
Protocol Working Group.

The IESG contact persons are Ned Freed and Ted Hardie

Technical Summary

These documents form the basis for a mechanism by which multiple
distinct Instant Messaging applications may pass messages among
the different systems while retaining the ability to use end-to-end
encryption, integrity protection, and a shared framework for presence
information.
The work on PIDF (Presence Information Data Format) is already in
widespread usage by the SIP-based instant messaging community,
as is the message format described.

Working Group Summary

The IMPP working group was originally chartered to develop requirements
and then protocols which would provide an "Internet-scale end-user
presence awareness, notification and instant messaging system". The group
delivered RFCs 2778 and 2779 defining a model and requirements for
instant messaging, but it was unable to select among the candidate
protocols for this task even after setting up a nine-member design
and review team. After this impasse was reached, the work of
development was split to allow for multiple, interoperable transport protocols.
While the tasks assigned to those groups chartered after the split
are relatively clear in their charters, the work to be done by IMPP
was, regrettably, not defined in a new charter. As a result, the
task taken on by these documents represents the rough consensus
of the group as determined by the chairs; there remains, however,
a view that the group was chartered to define minimal gateway
semantics for the multiple IM systems, thus rendering end-to-end
encryption and data integrity out of scope, rather than the formats
and framework defined by these documents.

In evaluating these documents, the IESG has thus both needed to assess
whether the documents meet the needs of the work plan as the chairs
have understood it and whether the work plan itself was on target. The
IESG greatly regrets the necessity of this second task and its failure in
not updating the charter of IMPP. It does not, however, believe that refusing
to advance the documents on the basis of this failure is appropriate,
as it is contrary to the promotion of interoperability in this arena. Instead,
the IESG has been guided by the charters granted to the successor groups,
by the place end-to-end security normally holds in IETF protocol
analyses, and by a careful review of the mailing list and minutes of the
meetings subsequent to the split. The IESG has, through this review,
concluded that the work plan described by the chairs was on target
and has conducted their technical review of the documents solely on
the question of whether the documents meet the need outlined by that plan.

In its technical evaluation, the IESG noted that many of the formats and
discovery mechanisms described are already in use or replicate well-known
existing mechanism. They reflect that maturity in their description
and completeness.
The core document on CPIM, in contrast, represents a fairly abstract
description
of the service. The IESG believes that the documents are of sufficient quality
to be the basis of an interoperable service, but notes that it
expects the development of documents mapping CPIM to specific
protocols to show how to make the
abstract terms in CPIM concrete. Further, it expects that
interoperability reports
presented for the transition to draft standard would include multiple
protocols,
as well as the usual requirement that the implementations be independent.

Protocol Quality

The documents were reviewed for the IESG by Ted Hardie.