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. - Agenda bashing (5 m) - Recap (5 m) - External perspective (Leslie D. from IAB) (10) - Identification. of issues (10 m) - Presentations (45 m) - Break - Discussion (30 m) - Wrap-up (15 m) Recap: 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. Presentations: 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. Break: Upon a suggestion from the floor, the group decided to forego the break and use the time for discussion. --- 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: * User Identity - discovering how to communicate with someone. * Access control rights -- who can view what aspects of someone's presence? * We need to finish elaborating schema and extensions for presence format. * [Meta issue] How does each proposal imagine that each user will use IM and Presence? * [Meta issue] Do we want IM to be built on something else, or not? * Can it handle application to application? * How would these proposals would implement push? (As in sending a small text message to a cell phone.) * Do clients do IM or do service providers do IM? * Scalability * Overhead, especially for short text messages. (It'd be great it a 10 char message can fit into a single packet.) * The requirement to maintain state at the server... * The ability to do some pipelining of state between messages when there is a relationship between messages. 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.