2.1.5 Instant Messaging and Presence Protocol (impp)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


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

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Patrik Faltstrom <paf@swip.net>

Mailing Lists:

General Discussion:impp@iastate.edu
To Subscribe: impp-request@iastate.edu
Archive: http://lists.fsck.com/cgi-bin/wilma/pip

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


No Request For Comments

Current Meeting Report

IMPP Meeting Notes

Chairs: Vijay Saraswat, Dave Marvit
Minutes-taker: Lisa Lippert (Dusseault), light editing by Saraswat

Discussion of chartering

There was an initial discussion about the volume of messages on the list in the past couple of months (over 600). Vijay suggested we publish a FAQ addressing recurring issues. He noted that the Chairs have not been very active on the DL, and would start playing more of a role of policeman. He pleased with folks to be careful about messaging the group.

People should go to the meta-impp list for more general discussion.

Patrick gave some IESG Feedback

Because of the scaling concerns, the protocol definitely needs to be efficient. Size of payload and number of messages need to be considered, to support wireless and thin clients.

We need to discuss that this week, and perhaps we must add text to the document to state these requirements. It might be the case that TCP is not the correct choice for this. When these questions have been cleared and it may be just a matter of wording or misunderstanding the RFCs are done.

Discussion of the proposed new charter

Dave: This new charter is almost entirely taken from the old charter we submitted to the IESG when we first tried to charter the group, before the IESG asked us to focus on requirements first. The requirements arent part of the charter, instead it says that the goal of the group is to design a protocol or protocols that meet the requirements document. The dates for deliverables are a little meatier than in the old version.

We came up with a list of separable deliverables: PIDF, MIDF, PITP, MITP (see charter).

Note that the transport protocols may merge into one, but not necessarily.

Graham Klyne suggested an overall service document, that describes how all these pieces fit together.

Chris requests that we not use the words transport protocol. Transfer or session would be better.

Jonathan Rosenberg asked what we decided were going to be the message formats, werent MIME types chosen? Vijay answered that the message format would likely be a very short document.

[Back to Dave.]
The schedule is aggressive. We want the data format drafts to be published by January.

Patrick: I dont like that the first versions of the drafts may not include security.

Dave: Part of the goal here, since the dates are aggressive, is to split out the first draft of the protocols.

Marc: From a security perspective, the only more complicated protocol is IPSEC. We wont be able to just add SSL later. It must be considered now.

Josh: People can make the IMPP security model very complicated, but perhaps we can have a first draft with a reasonable amount of security rather than everything.

Back to Dave: We may even split out the protocol documents between client-server and server-server protocols. Dave Crocker will speak about this.

Dave Crocker discussion of server-server vs. client-server protocols

The model in all the discussions has been pretty classic. (Drawing of client server server client diagram). There are a number of protocols like this, it is required for scaling, Email is like this, but so is the web (with proxies of the servers). The IETF has seen people do things in small-scale, they dont know how to scale them large, so they help with that. It occurs to me that we might have the reverse problem here.

Why do we need a server? It may or may not be right, but we may want to consider that clients that occupy the same area can deal with one another without loading a server. The first question is whether this is a scenario the group wants to see investigated. There is interest in wireless, zero-configuration networking. We dont do dynamic address assignment without a server, and thats a prior arrangement. Imagine you are in a meeting, and you have your infrared channel, and you want to talk to a cohort without involving other people.

Its fascinating to me that we have two protocols in email, for posting/delivery vs. relay (between servers). They look the same, but they're on different ports, and the reason is the freedom to evolve.

This is why the charter asks whether the WG should consider merging the two transfer protocols, but also consider breaking them apart into C-S and S-S protocols, and consider whether to do away with the servers altogether. If this group wants to get a working service, theres a real challenge, because taking two years to get a requirements document indicates the time required to get a protocol, and we may want to scale things down rather than scale things up.

Chris: Dave Crocker missed a model that isnt like email, and thats that a big honking server is put up to support all users. Its proven to be able to be deployable, and we need to think about that.

Question: The model document is very interesting, and there are really six or seven different arrows that are interesting. Perhaps we should pick different protocols for each arrow.

Keith Moore: Without entirely agreeing with Dave Crocker, some of the same concerns have occurred to me. The notion of the separate server and the role it plays, and the trust model. I dont think the group should assume a centralized server, but I dont know if they can do without it.

Mark Day: Clarification: the discussion of the centralized server is in the basis document, which is not a WG document.

Vijay: There are services out there that support very large centralized servers, and thats just a reality. We need to consider the problems of gatewaying to that.

Keith: Oh yes, but it should not be the goal of the group to support that business model.

Suggestion: In the role diagram, Ive always assumed that an actual client machine could take on both roles. A client may take on more.

Question: Why do we need server-to-server interoperability? If I am a client, and I know that another client is hosted by a certain server, then my client can talk to the server that hosts that other client. Why does my client need to talk to a server which needs to talk to another server?

Vijay: This has been brought up before.

Keith: If I want to say my presence server has such and such an address, thats my decision. Its possible to support both models. I dont want an architecture that requires the intermediary in all cases, and that was my point.

Dave: I think the model document doesnt specify the answer to that, maybe we should put it in the FAQ.

Marc: The Zephyr implementation has tried this both way. It is convenient to have clients able to talk to servers, but for scalability it is necessary to be able to have servers talk to servers.

Keith: An ISP doesnt have to be part of the loop. If my ISP doesn't have this functionality, I should be able to go to some other service providers. We shouldn't assume that it is the ISPs right to control this and give advertising.

Sonu: The goal for this group has always been to support an administrative model similar to email.

Dave Marvit: Lets return to the list of deliverables.

Question: Does [the presence format document] include the online encoding of presence state?

Dave Crocker: First of all, the real importance of a list like this is to try to outline the areas of focus, and if the group ends up trying to merge things, even if the charter says one thing, the group can deliver another. Looking at this list, it ought to be clear that the group understands that presence is separate from instant messaging, even if they are described in the same document. It should be recognized that we need to talk about these and resolve them independently, even if the answer can be summarized in a one line document.

Jonathan R: I agree with Dave C in principle, but we have been rolling around for two years already, and I thought we had decided we didn't have to decide on the format specifically, but now that were putting together a list of deliverables, why do we have this item? It detracts from what we really need to worry about.

Vijay: It could be a brief document, but it needs to be someplace.

John Stracke: My concern on the MIDF document is that the metadata will be so bound up in the protocol that it should be included with the protocol document.

Vijay: Its possible for the group to list 4 or 5 documents but deliver fewer (including possibly the service integration document suggested earlier.)

Dave Crocker: RFC2305 is an example of this kind of document. It should not be called a framework, it is a service integration document. Its how somebody might knit these protocols and formats together.

Graham Klyne: I almost agree entirely with what you just said, except must instead of Might.

*** Hum on whether this is an acceptable list of deliverables: Hum in favour.

Discussion on Goals and milestones (Dave)

The notion here of submitting drafts without security information is controversial. It is merely a way of getting things going. It may be a mistake to submit drafts. That said, is it OK to circulate partially-finished drafts without full security information?

Suggestion: You may find that the service integration document is a good place to identify issues and current thinking about how to deal with those issues.

Marc: Security is not something you can bolt onto a protocol later, it must be there from day 1. A general security model of who authenticates to whom needs to be there from the beginning.

Somebody: That doesnt go against what was suggested. If the system integration document says this is the way the integrated system must operate, then its security requirements apply to the others. Then the other documents dont need their own security sections at the beginning.

Somebody: Authentication is in the protocol, this needs to be in the documents.

Perry Metzger: Rather than simply relegate security to the security considerations section, I suggest that the one thing Ive found to be a problem in documents like this, when the security considerations arent mentioned all along, readers wont understand how it fits together. Integrate the security into the document as a natural part.

Vijay: Theres a bit of a dilemma on this. Its clear that security considerations are a big thing for these documents eventually. The problems we are facing are procedural. Most of the discussion has been on non-security issues. We want to capture that progress and nail it down before continuing on security issues.

Dave Crocker: Thats a good summary of why I beat up on a charter last night. The first draft is not delivered out of the working group its a way of making progress in the WG.

The group has to divide the hard stuff out.

Sonu: Weve started to take into account security, we realize we may eventually need to do end-to-end encryption. These discussions will happen , but as a process thing, to get the first drafts out quickly, we need to do this.

Harald Alvestrand: Please remember who we are doing this for. We want a secure protocol because otherwise the users lose big time. On page one of document one, you need the security model. I agree that you can sketch out mechanisms in documents that dont say how to bolt on security, but the model for security has to be apparent from the first page of the first draft of the first design document.

Dave Marvit: Its in the requirements document.

Harald. Thats not a design document.

Keith: Yes. Any document that does not design trust relationshiops and explain how to exchange between two parties you cant do except from day one.

Charles Perkins: I believe the integration document is the place where all the important stuff lives, so the other documents might not need all that.

Mark Day: I ve written some of these documents, and am hearing many fine words about what needs to be written next. I hope that the chairs will take some of these suggestions and also get some of the suggesters to help write the documents.

Vijay: Yes. In particular there has been a community that has been saying this security stuff for a year but has not contributed to documents. Where are you.

Charles Perkins: I will volunteer to work on the integration document.

The goals and milestones document was revised to remove the clauses potentially not security from May 2000 onwards.

Vijay: Is this good now? The first four documents (before may) are internal to the WG only, not published I-Ds.

Keith: If you try to make progress on issues without doing security, you will throw security away. If you treat these documents as milestones of the group without security, youre giving them way too much importance.

Vijay: We face a challenge of getting the security folks involved in this design, and we will work with our chairs to get help with this.

Patrick Faltstrom: Ask yourself what youre going to talk about in Australia if you dont have security worked on by then.

Mark Day: I would suggest we slip the schedule by a month or two to allow for including security in all the documents.

Harald: I think the right thing to do is for the WG chairs, the volunteer document editors to meet after the session, find out whos got the largest suite, go there, write down a two page security model document, and not leave the room until youve got it written down. This isnt so hard.

Dave Crocker: This isnt so hard doesnt reflect the history of the group.

Harald: Write down something. Youre much further along by writing down something that people can throw stones at.

Dave C: Everybody in this group seems to need to comment on every detail, so its very hard to make any progress in this group. If resolving all of the security issues has to been in the first draft, then it will take a long time. The first draft doesnt go to the steering group, so theres no question of whether the steering group would approve the first draft.

The final draft goes to the steering group, not the first draft.

Vijay: The proposal is that we start working immediately on security considerations

Harald: No, security design. Not the threat, but the design how you propose to solve.

Vijay: Thank-you. We will actually have a presentation later today, if we can get to it, how to solve this problem. Can we do a security design document by March?


Marc: There are a number of other issues, which while we cant finalize them without security, such as what transport, and there are number of other issues we can talk about in parallel with the security issues.

Charles Perkins: I cant speak for those other four points, but if Im working on the service integration document, it will be started now, and continued until its delivered, and we will talk about it even if the security is being worked on separately.

Assigning Authors (Dave)

Now we use the social pressure of a large group of people to press authors into service, especially security people. Do we have any volunteers?

Marc Horowitz, Stephen Williams, a couple others volunteered.

Security Outline Presentation Shingo Fujimoto

We started from the requirements document, and we are almost done. We worked with Mark and Greg and some other people who worked hard to identify the items we need to decide. However, some of the items were not discussed deeply, so Ive had to do some interpretation.

- Data Security
- Message Integrity
- Authentication
- Encryption
- ACLs
- Firewalls

Slide 3: Message Integrity
There are several definitions of message integrity. Some transports are deemed reliable.

We need to make sure nobody can modify my messages. There are several known ways of solving this problem. The first technique is using the public key for digital signatures. This may not meet our performance requirements. Keyed MAC involves shared secrets without public keys. This may meet our performance requirements, but sharing the secret is a problem.

The third one is my recommendation, to use public keys to get a symmetric keys, then use keyed MAC to get good performance.

Slide 4: Authentication

For authentication, the simplest solution is password-based authentiocation. But if we dont have transport protection, that could be read on the wire. The second way is challenge response, but it requires an account for all possible users.

Third one is the public-key-based Challenge/Response. If we can assume some kind of infrastructure like PKIX, and can register CAs Perry: If you assume the presence of a public key infrastructure, none of this will be deployed. There are so many bugs in CA systems, they never find their bugs in the protocol itself.

Chairs asked that comments be kept until end of Shingos presentation.

Slide 5: Encryption
I only discuss the meta-level security.

Transport encryption, e.g. SSL, TLS. Its easy to add on to protocol, but the drawback is flexibility. We need more flexible encryptions, according to the requirements document. Another option is msg-level encryptions, like SMIME. This offers more flexibility, but at the same time, we need our own services to provide the raw level security for exchange and session management.

The third option is intermediate: using the message security for messages, and the transport-level security for guarding the basic data transmission.

Slide 6: Topology

Our security problem is not general. Our typical topology on the Presence Information (PI) system: the presentity will be one entity, but the receiver will be the master receiver.

In the requirements doc, if the presentity wont do that, so that the administrator cannot see that traffic, the server needs to provide a virtual connection.

Slide 7: Summary:
Shingos draft is available at: http://www.imppwg.org/meetings/199911_washington/impp-security-fujimoto.ppt

Commentary on Security Presentation

Marc: You dont seem to make any allowances for Kerberos, or any symmetric key exchange protocol in general. One of the issues here is that you have a domain with already-deployed security infrastructure, the protocol needs to be general enough to drop into the infrastructure. Youre 20% into the path that Ive seen other WGs go down, and we might as well stop now.

Shingo: This is not a proposal, just a description of techniques and recommendations for choosing them. We welcome your comments to the next draft.

Perry: I find myself disagreeing with Marc. I think that having too much flexibility and trying to please everybody means not coming to closure. This is an issue of getting the work done. Most of what you said about sealing the objects rather than the streams, I cant disagree with you. The question I've got, is it really your intent to rely on PKI systems to get this information across the net.

Shingo: We cant assume that PKI is ready. We need intermediate solutions. The most important part of my proposal: if we can assume that a certificate is usable, we can get the benefits of that infrastructure.

Perry: So its not your intent to handcuff this to PKI.

Mark Day (pointing to Topology draft): This slide does not represent the model document.

The piece at the top should say presence service, not presence server.

There was a conscious decision that there is no requirement for a central server, and I want to make that point again. The model supports a system in which the client itself provides the service.

Lawrence ? of Qualcomm: On a small device such as a Palm Pilot, we find you can't do RSA sigsn and encrypts quickly. On a 60Mhertz processor, trying to do RSA, youll find the performance is unacceptable. For SSL, those operations are done on the server, so SSL can be done on the server. In SSL, you're going to authenticate the host What I'm saying is you're going to have trouble doing message-level public-key security on small devices because of the performance problems.

Shingo: We assume the user on the wireless system might be okay, but we dont know about the connection, and we cant compromise based on the bandwidth.

Lawrence: Its not the bandwidth, its the client processor.

Shingo: Perhaps the gateway can help with this.

Lawrence: An alternative is elliptic curves, which solve the problem, but thats kind of outside PKI.

Keith: I share Lawrences concern about CPU on devices, which makes one think twice about RSA or Diffie-Hellman. The SSL model assumes a certain kind of trust, that the client trusts the server but not the other way around, even though TLS supports that, it doesn't support it very well.

Charlie: When we decide if the C--> S and the S S are different, we may be able to finesse this problem.

Perry: If youre comparing apples to apples there are ways to finess that on small devices, e.g. link authentication between a telephone and a switch, and have the switch encrypt for you. The fact that youre attempting to get end-to-end encryption of the message makes it difficult to use the SSL model.

Harald: The picture on the screen is what comes closest to what I think about as a security model. You start thinking what kind of protection is given to messages, and who trusts who on the system. Sometimes you want the service not to know the content of the message, but the presentity and the watchers know it. Thats where I think this draft can benefit from much more discussion to work towards the security model. The choice of algorithm is sometimes a given you simply calculate from CPU what you have time for. If you find you have different requirements in different parts of the system, you may have a modle with multiple trust domains and interactions between them. You might have a powerful server signing messages for palm pilots which may be anathema to security people, but which may be necessary. Youre doing good work, you need to do more work.

Discussion of Basis Document Mark Day

Weve had lots of people in past WGs come up and describe their implementations in 20 minutes. When we got together out of the IETF, we were able to spend much more time delving into this.

This basis document is just what the four authors think, not a WG document. In the meeting in SF, we went through this in some detail.

Some people on the list have suggested that Microsoft and Activerse are conspiring to get their protocol accepted, and man, thats just not what happened.

I think theres still rough consensus, even after the DL traffic, on these points:
- TCP as substrate
- Extended-email-style naming (RFC-2303) e.g. imp=Mark_Day@lotus.com
- Server-server TCP connections: shared, long-lived, may need to be opened manually
- Simple XML basis for presence format
- Presence as MIME object: exact type is contentious
- RFC 822 style as basis for IM format.

Keith Moore: Ill start with the RFC2303 thing. In some sense, I think it doesnt matter what these things look like. But RFC2303 is an attempt to bridge the world of phone messaging and email messaging, and in the long run its irrelevant. I dont see it as a model for IMPP to emulate. You dont talk about whether or not to multiplex TCP connections here, but Ill be very surprised if you can make server-to-server TCP connections work without multiplexing data over them.

Mark: Thats what we intend.

Keith: Maybe all those points need to be reconsidered because of wireless. Im not sure how that affects.

Mark: If wireless affects all these points so much, perhaps it should be ruled out.

Keith: I dont think so. Half of the internet could be wireless soon.

Vijay: Id like to get clarification from the ADs. Should we consider wireless?

Keith: This is why we need to get the model and requirements documents approved first. But yes, we need to talk about how important wireless is and what its requirements are and how to work well with it. What percentage of the internet is going to be wireless? How well do gateways work? Is bandwidth going to continue to be so expensive for wireless? This doesnt necessarily mean changing requirements or design choices. If the design choices have already been made in light of wireless considerations, how have they been made, etc.

Vijay: The WAP forum people have gone down the route

Keith: WAP needs to be viewed as a short-term solution. It was designed to retrofit. Its clear theres a huge market for IM. Once you settle protocols, you find they stay around for much longer than you expected.

Vijay: Id hate for the IMPP group to become the group in which a new high-level framework for wireless was invented.

Keith: Any WG could be the cutting edge. Earlier the IMPP WG was telling me they didnt want to be the group to figure out how to do the application level security well, and thats tantamount to saying that security isnt important to IMPP, or wireless isnt important to IMPP.

Vijay: Do we assume that devices support TCP/IP? Have IP addresses:? What basis can we work with?

Keith: You can assume that they support TCP/IP, but you may not think thats the best solution.

Josh: I think that overall, we have to be mindful of the wireless environment. However, I dont think weve made our decisions without considering wireless issues. WAP has pessimistic assumptions. In the future, theyve defined a plan for conversions, back towards internet standards for integration, not this special WAP stack. I dont think we need to do things over again because of wireless devices. Moores law also affects them. I dont think XML or MIME is a bad thing. They dont have a TCP equivalent, but we could have one. In short time youll have GPRS which is a packet-based network for these devices.

Email used to work over 14.4. Wireless devices support the same bandwidth today. I dont see why we dont think this will work.

Sonu: Just about any protocol could consider wireless. I think the way to go there is a gateway. On the RFC2303 issue, it seems to me we didnt come to a final decision.

Mark Day: Yes, lets get back to the issues on the screen and not go down the wireless rathole.

Mark Day: The discussion of RFC2303 was definitely late on the second day in SF. My point is that this is something we ought to be paying attention to. Whereas there is a lot of argument of what is a URL doing there at all, by the end of the discussion we thought we could use 2303 as the basis for using a mailto address to achieve the same lack of ambiguity that we were looking at URLs for.

Marc: The problem with using XML for presence information is it's a monolithic object. If presence is going to be limited, thats OK, but if its going to have all kinds of information like fax address, email address, favourite colour, I dont need all that to send you an instant message.

Mark: Effectively, a piece of presence is a resource, and can have variable granularity. You could break it up: heres the piece about my cats presence, heres the piece about my online IM presence.

Marc: A lot of the services that TCP provides are services that we want: messages larger than a packet, etc. Given that, we have a choice of implementing all those services on another protocol or using TCP. I believe that the implementers that chose UDP found it to be a mistake.

Mark: I think that was indeed Gordon Mohrs (Activerse) attitude.

Harald: Service-service protocol is very important. However, if the architecture of the system is that one client talks to one server, then the choice of local transport has no effect on the entire system, so can be left to local choice. The reason why XML is important, if youre going to sign this piece, you need to talk to XML DSIG. Once you sign an object, the server cant break it up and send it out in little pieces. So, I like this.

Colin Benson: It seems that most of the 600 or so mail messages Ive gotten in the last couple weeks have been about XML or MIME types. I may not have read them carefully enough, so I wondered if you [Mark] could tell us what the result is.

Mark: Im just summarizing the SF meeting. My impression is that an awful lot of what has been happening on the list is people talking past each other about what these things mean.

For example, the discussion on simple XML seemed to disappear in a puff of smoke as people said oh if thats what you meant, why didnt you say so. Similarly, the MIME discussion may have a similar misunderstanding.

Colin: When is this discussion going to go away?

Mark: Ive attempted to suggest taking out contracts on peoples lives, but

Vijay: Weve alluded to how were going to go forward in the midst of a flood of messages.

Id like to know about peoples attitudes for or against the points raised. Somebody like Mark will write up these points for the list. Hopefully one iteration, and were done nailing some of these issues.

Mark: We could also hope the chairs would get a little more assertive and keeping order.

Jonathan: I find it amusing that theres all this discussion on what the MIME type might be for a format that doesnt even exist yet.

Mark: Thats because you want to solve the problem rather than argue about it.

Jonathan: So I have a question about TCP. Was the agreement in the SF meeting that we recommend TCP for server-to-server? I personally like UDP

Mark: The drafts that present the groups design will say it runs on TCP. Others are welcome to go and describe how it runs on UDP, but thats not part of the group effort.

Charlie: We may want to think about a TCP-like substrate. Id like to say again: If the client and the server are not on the same machine, we can come up with some way for them to talk to each other in the local system. This can all be finessed by the structuring, modeling thing.

Karl Neumandros: We understand that these objects can be addressed by a URL. Can you address them with a mail URL as well? The other question I have, does 822 style exclude MIME?

Mark: No, it enables MIME.

Chris Newman: Im concerned with RFC822 style messages and MIME

Keith [something about UDP]

Charlie: If the client and server live on the same box, its dual stack, but only the server needs to be dual stack, it can make any kind of connection to the client, which doesnt have to be dual stack. The only problem is security. At least in my mind, I can see how this problem goes away, so we should have an offline discussion.

Jonathan: Its easy to say that clients support either UDP or TCP , servers support both.

Keith: Whats a server?

Requirements Document Discussion

The editors report on what they've been working on. Sonu should publish his slides.


None received.