2.1.3 Instant Messaging and Presence Protocol (impp)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00


Vijay Saraswat <vj@research.att.com>
Dave Marvit <dave@marvit.org>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:

General Discussion:impp@iastate.edu
To Subscribe: impp-request@iastate.edu
Archive: http://www.imppwg.org

Description of Working Group:

This working group will eventually define protocols and data formats necessary to build an internet-scale end-user presence awareness, notification and instant messaging system. Its initial task is to determine specific design goals and requirements for such a service. The design goals document will be submitted for IETF-wide review, and based on that review, the group's charter will be extended.


Instant messaging differs from email primarily in that its primary focus is immediate end-user delivery. Presence information was readily accessible on internet-connected systems years ago; when a user had an open session to a well-known multi-user system, his friends and colleagues could easily tell where he was connected from and whether he was using his computer. Since that time, computing infrastructure has become increasingly distributed and a given user may be consistently available," but has no standard way to make this information known to her peers. This working group will design a system to address this need.


The working group will develop an architecture for simple instant messaging and presence awareness/notification. It will specify how authentication, message integrity, encryption and access control are integrated. It is desirable, but not required, for the working group to develop a solution that works well for awareness of and communication with entities other than human users.


Providing a general notification mechanism for data other than user presence information and instant messages.

The following keywords describe the scope for the working group. Details are to be developed in the architecture document which is the output of this working group:









The working group plans to deliver the following document:

- Requirements for Instant Messaging and Presence

Goals and Milestones:

May 99


Submit Internet-Draft of Design Goals for Instant Messaging and Presence Information

Jul 99


Submit design goals Internet-Draft to IESG for publication as an RFC


Request For Comments:







A Model for Presence and Instant Messaging



Instant Messaging / Presence Protocol Requirements

Current Meeting Report

IMPP WG minutes
Aug 1, 2000 Meeting

The meeting was chaired by: Vijay Saraswat, Dave Marvit, and special guest chair, Leslie Daigle (present as an IAB Member).

An agenda was agreed to.

Dave M. presented a brief recap of what has happened since the last IETF meeting (in Adelaide). Several protocol proposals were submitted. The Chairs made a proposal as to how the WG should move forward in the context of these multiple submissions. This was met with considerable discussion. About a week later Patrik made a proposal which was also met with considerable discussion. In neither case was the proposal met with enough support to constitute rough consensus.

External perspective:
Leslie D. presented a high level view of the issues about the problem and the path(s) forward. She stressed that bashing competing protocols was not a fruitful part of the process at this stage. Further, the nature of the current impasse may be reflective of the fact that the different protocols are solving legitimately different goals. Ultimately this may lead to multiple fielded protocols. If there are multiple protocols, there will be an insistence on having one data model/format, having a structure that enables gatewaying, and justifying having multiple protocols in terms of the distinct features and applications that they enable. The development of multiple protocols merely because participants are unable to reach a consensus is not acceptable.

Identification of issues:
This time slot was intended to allow people to comment on Leslie D.'s presentation. There were no comments.

There were three presentations made, 1 for each major protocol group.

Jon Peterson made a presentation about the SIP protocol. He emphasized that the SIP community was fairly far along already. For example, an implementation has already been released to the Internet community.
"Doing it with SIP is low hanging fruit."

Pete Resnick introduced a presentation by Dave Crocker. Dave C. provided a high level overview of IMXP. He pointed that there is both a signaling requirement and a messaging requirement for IMPP. While SIP starts from the signaling side, IMXP starts from the messaging side.

Athanassios Diacakis (aka Thanos) discussed the 'Group II' protocols. He emphasized that the authors of four of the group II protocols have coming together to create a single group II proposal. They also anticipate a rapid timeline.

Upon a suggestion from the floor, the group decided to forego the break and use the time for discussion.

There were many comments that foregrounded the shortcomings, or the presumed shortcomings, of one or more protocols. (For example: "I'm not a big fan of SIP. It does a good job of solving what it is supposed to solve, but I'd hate to see it propagate.")

Leslie, Patrik, and the chairs did their best to constrain the discussion to useful distinctions between the protocols that emphasized the difference in features and user experience without 'bashing'.

Jonathan Rosenberg opined that "This discussion of a split into groups has led people to think that SIP is architecturally different. You can still do all the things with SIP that the other protocols allow." He added that one of the merits of a SIP approach is its compatibility with the ongoing convergence of communication services.

Leslie D.: If there needs to be a SIP answer to the IMPP problem, there will be. The issue is: what are we going to do to move forward. How do we distinguish the different solutions if there are multiple ones? That's the issue here.

Patrik: We need one WG that outlines the data model. All of the other working groups need to reference that.

Charles Perkins: And if they all submit a result?

Patrik: That's OK. But the IESG isn't ready to make a call now. But do you want multiple implementations? We might make a selection some day (as with IPSEC).

Leslie D.: When proposing new WGs we need to define the distinguishing characteristics of the new proposals. It won't be the nitty-gritty details that make or break these proposals. These will not be children of the IMPP WG. They will be related WGs. And as such they need to justify their existence to the IESG based upon their different requirements and goals.

There followed discussion about the merits and drawbacks of splitting into multiple working groups. Arguments included (paraphrased and not quite in original order):

Larry Masinter "We need to resolve about 6 technical issues. That's best done together. Then we can split if it seems appropriate in the context of the results of that discussion."

Mark Day: "If we split it up we will divide the people who are making valuable contributions on each other's proposals."

Keith Moore: "I have seen the process of splitting before. It kind of works when nothing else does but it is a truly last resort."

Josh Cohen: "There are people coming from different enough centers of gravity that a split is likely to be the only way to move forward."

Keith Moore: "We can't end up with one single protocol. For example, we need a light weight one (for wireless) and a heavyweight one.

Leslie D.: Rather than debate this issue, let's focus on the elements that we should be drilling down on. This will help compare the different approaches.

The following issues surfaced:

Marshall Rose: The problem we have is that there are 2 + N groups that have different views of what should happen. All of the stuff is technically good, but people think the other is the wrong way to go about it. For example, should the emphasis be on the instant (SIP) or on the messaging (IMXP)? Both are valid technically. Because of this, no amount of debate will bring both sides together. While I can see a lot of merit to making the data models the same, we are just miles apart on the other stuff.

Leslie D. called for a hum as to whether or not we should split the WG. There was a medium hum in favor. (It seemed to represent a significant constituency, but not an overwhelming majority. -DM)

Leslie D.: The problem is that each group hasn't explained their justification for existing. If you can't explain it here you won't be able to explain it to the IESG.

Patrik: OK, I'll decide and present it here and now. Based upon the response to Marshall's comments and to Leslie's question I see a plan taking shape. What is common should be dealt with in some common space. The non-common stuff can be dealt with in the non-common space. What I want is the name of 2 or 3 people from each of the groups. The three groups must come to agreement as to what is common and what is not.

The group accepted volunteers. A date of Aug 21, 2000 was set for the initial report from the group.

The volunteers were as follows:

Athanassios Diacakis
Florencio Mazzoldi
Hiroyasu Sugano
Robert Sparks
Christian Huitema
Jonathan Rosenberg
Marshall Rose
Graham Klyne
Dave Crocker

(Email addresses of these nine are available from the I-Ds they submitted June 15, and from their messages on this list.. an explicit list available if there is demand.)

The meeting was adjourned.


IMPP - Extra - WG Perspective
Outline of IMXP