2.1.3 Instant Messaging and Presence Protocol (impp)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99

Chair(s):

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.

Background:

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.

Goals:

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.

Non-goals:

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:

- PRESENCE

- INSTANT MESSAGING

- SHARED

- NAMING

- AUTHENTICATION

- ACCESS CONTROL

- SCALABILITY

Deliverables:

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

Internet-Drafts:

No Request For Comments

Current Meeting Report

IMPP WG Meeting Notes
Friday, July 15, 1999
Chairs: Vijay Saraswat, Dave Marvit

Agenda:
- Administrivia
- Model document
- Requirements draft and open issues
- Update to charter

Once again the meeting of the IMPP working group was energetic. The primary focus of discussion was the requirements document. The document is close to being completed with only a handful of open issues going into the meeting.

Consensus was reached on a number of the open requirements document issues. Those issues that were not closed out were referred to the mailing list. The majority of these revolved around disputes about exact wording.

Presentations were made about:
- The Model Document
- The merits and demerits of having a common protocol for IMs and Presence
- Is IM/PI Presence-Centric or Messaging-Centric?
- The Requirements Document

Details of the meeting are reflected in the notes below (thanks to Lisa Lippert).

MODEL OVERVIEW -- Mark Day

Model, Requirements, and Protocol

The model is an attempt to construct terminology. It is descriptive, not prescriptive, and doesn't concern interoperability.

Requirements: we take the concepts described in the model and define what the system has to do minimally. These describe what the system has to do, not how.

Interoperability matters. The protocols and formats to be defined are prescriptive, complete, and must achieve interoperability.

Why Presence is like Instant Messaging:

The presence service, in the model, is distinct from the messaging service. The presence service has "presentities", which provide information to the presence service, and watchers, which receive the information from the presence service. In instant messaging, the presentity maps to the sender, and the instant inbox maps to the watcher, with the instant messaging service providing the same functionality as the presence service.

The presence service may have multiple subscribers (and possibly pollers and fetchers) to the same information. Similarly, the IM service may have multiple instant inboxes to send to. The difference is that the presence service holds onto presence information, whereas the IM service passes on its messages and drops them.

Protocols and Formats to be Defined:

The model discusses people (presence user agent, watcher user agent, etc) but the protocol and formats to be defined are not directly used by those agents. The protocol/format defines what happens between the presence service and presentities/watchers, and between the IM service and senders/inboxes.

REQUIREMENTS ISSUES -- Mark Day
- One protocol or two?
- Single Namespace for IM and for presence?
- Enumerate minimum status codes? Currently open/closed and avail/busy/idle
- Are message-ID's to be required?
- IM delivery failure: when a failure occurs, must/should the service notify the sender?

Jonathan Rosenberg: The question of whether message-id's are required is a protocol design issue, not a requirements issue. Is there a requirement for a feature that message-IDs would satisfy?

Mark Day: This was discussed under threading, but the more important feature was debugging.

Derek Atkins: What does delivery mean?

Mark Day: Placed into the appropriate inbox, such that the system is done with the message.

One Protocol or Two -- Gordon Mohr, Activerse

Are presence and IM different enough that we should design two different solutions? How much overlap is there? With separate protocols like 'finger' and 'talk', people often use them in quick succession. Does the same address work for both?

One Protocol: Advantages
- Completeness
- Shared namespace and facilities

Two Protocols: Advantages
- Cleaner decomposition
- Separable Implementation
- If an existing protocol would solve the problems of one of either IM or presence, we could adopt that existing protocol.

PI Atop IM

- Special instant messages ask for or carry presence information and subscription control traffic

IM Atop PI

- IMs are a special kind of notification, a notification carrying custom text for user view.

Note that we will need to have recommendations for solving both at once, because most of the implementers that want to do this want both; even if they are completely separate we want a way to tie a bow around the two and be able to say that an implementation is PI/IM compliant.

John Ardberg: I'm not sure I followed why two protocols need to be interrelated?

Gordon: We have to present them together because of the high level of interest in the two together. Existing proprietary systems make little distinction.

John: But the namespace can be the same without the protocol being the same. Are you assuming that they can't be independently useful?

Gordon: The two together are much more useful than either alone, so a

Henry: I think your model is both incomplete and broken, because there are many communication modalities besides instant chat. You can do more: you can start a voice conference, you can share web pages, and we've seen this use. On the chart I see, I like "sessions". Sessions cover a lot, not just instant chat.

Dave M: I'm not sure if you're talking about Mark Days' presentation or Gordon's discussion.

Henry: Maybe the charter is broken. Once you have presence, there are many sessions you can launch besides instant chat.

Larry: The namespaces could be neither same nor distinct, but overlapping. You can have some addresses that do only one, and others that do both PI and IM. Trying to make a decision about one or the other sets up a false dichotomy. It's useful that you've laid out the common case for instant messaging, without saying that's the only way in which IM occurs. The model is only complete in that all good models are incomplete, causing the group to focus.

Pete Resnick: This is an argument for separation. If the protocols mush into each other, that confuses the case with the model that tried to keep them separate. You can define how two protocols interoperate even if they are completely separate.

Tony Genovese: I want to see more about who wants to use presence information: I want to know when somebody is present for teleconferencing, or video conferencing.

Mark Day: This is a rehash. The area directors and past meetings have stressed that we don't want to take in all of that. Presence information is useful in and of itself. Gordon should go on with his presentation.

A slide was presented showing the spectrum of characteristics between IM and PI.

This is an idea that comes up often on the list:
IM Conventions | PI Conventions
-------------------------------------
Common Transport

We have to deliver both IM and PI.

Tony: You don't have to deliver them at the same time.

Gordon: Yes, but...

Namespace Issues

- One address usable for both PI and IM?
- Must 2 addresses be used?
- Can 2 addresses be used?
- Are capabilities evident from address?
- The single namespace allows flexibility, but requires probes/retries to see if the address does or does not provide PI, to see if it does or does not receive IMs.
- Can you subscribe to an IM-only address?
- Can you IM to a PI-only address?

Gordon: I am in favor of the common namespace.

James Kretchmar: If your charter, in this WG, is to write requirements, then this whole discussion appears out of scope, unless your requirement will say "there shall be one protocol".

Vijay: That's the question -- should the req'ts specify one or two

Kretch: That's only justifiable if you say what the functional requirements are that...

Keith Moore: You can give the feedback to the ADs if it appears you need to do this separately. Also, there is likely to be a WG called ResCAP, which will provide a service to do name lookup. It will take a URL that has a DNS address, and look up information about the capabilities of the URL. This will be useful for you if you go with single address. I think this group should work with the RESCAP service, because it will be very usable across several protocols. The charter needs a bit more text about security, but the group is nearly formed. There are two strawman protocol documents.

James Kretchmar, MIT: I think it is inappropriate to discuss one/two protocols in the requirements document, and is more important to discuss when you're discussing the architecture. Second, I think it is appropriate to discuss presence in this group. You may want a situation where you ask for a person's presence, and the server might find out if this will happen based on ACL.

Jonathan Rosenberg: I think there's confusion about what is an address; an address is just a place, where someone is. We have an address, and we have a service, which is the thing we want to do with that address. Since IM is different from PI functionally, we've heard why they are independently useful, so I prefer the URLs to specify different protocols.

Keith: I would be inclined to say that the two must be separable. You might want to receive instant messaging entirely elsewhere from where your presence information is published.

Jonathan: I am very interested in presence for IP telephony, not for IM. These are clearly separate services that can be provided separately.

Nick Shelness, Lotus: Just because a protocol supports both services doesn't mean that a service must do all parts of the protocol. I'm hearing a tremendous amount of religion not justified by the technological concerns. The functionality is whether you can provide IM separately from PI, not whether the protocol separates them.

Keith: The functionality is also whether a user can provide PI at one address and IM at another address.

Gordon: Is it a requirement that the user be able to use one address for BOTH?

Jonathan: Address or URL?

Keith: Out of scope.

The WG decided:

- "IM and PI services must be able to be provided separately" is a requirement.
- "A user must be able to do PI at one identifier and IM at another identifier" is a requirement.
- "A user must be able to do PI and IM at one and the same identifier" is a requirement.

Addendum: where an identifier is something that a person will see.

Argument ensued over URI vs. address vs. identifier

Patrick Faltstrom: Rephrasing what Keith is saying: What you are talking about in this room is PI and IM and how to pass this around, and this is done with certain addresses or identifiers. Those addresses are something completely different, probably, hopefully, from what goes on their business card. The mapping from an email address, which goes on the business card, to an IM or PI address, which does not, is out of the scope of this WG (might be in RESCAP).

Keith: The one thing I would add: If you have the layer of abstraction that takes something that looks like an email address and returns a real IM service address...

Gordon: My question: if someone wants to advertise their PI/IM address before this RESCAP is available, which should we lean towards providing? I like to put my PI/IM address on my business card, it serves both as an address and a flag which says "this is a way you can communicate with me". If there isn't yet a lookup system from email to arbitrary other functionalities, which should we lean towards.

Patrick: Not specifically RESCAP, but some magic indirection between addresses -- when you say address, it's very important to clarify whether you are talking about including or not including this abstraction layer.

Kretch: One of the reasons we're debating this is because it has a great impact on end-to-end vs. involving proxies. I'd like to know if this is appropriate for requirements before we decide if it is a requirement.

Nick S: The whole purpose of a presence service is to determine where an entity with a presence is.

Vijay: Your discussion makes sense if you assume that the services are together. If there are IM-only entities and presence-only entities, it makes less sense.

Keith: People might have a different idea of PI and IM than I do. I don't know why IM can't go to my pager. This may have nothing to do with presence.

Derek: We've already said they can be separable. And that they can be together.

The WG decided that the requirements hummed over above stand.

Anonymous: The problem is much more complicated, but perhaps the answer to the simple question must become more obvious. There may be multiple occurrences of me being present, but I only want one identifier on my business card.

Anonymous: When people invented URLs, they said that it doesn't matter that URLs are ugly, that people will never see URLs. This was not true. If we invent new names, we cannot say that they should be hidden because of some wonderful directory system, but you know people have been talking about this for years and nobody has been successful, and many think it to be impossible. When you asked for humming "do you want people to use the same identity for IM/PI", you should have also asked if they want the same identity for IM/PI and email?

Vijay: We can't get into that.

Klaus Wolf: What about subtractions from the requirements?

Vijay: I'd like to defer that until we might finish the issues already identified.

Anonymous: I don't know if the user could make the decision on whether these can be separate or together, the service provider will make the decision.

Is IM/PI Presence-Centric or Messaging-Centric? -- Sonu Aggarawal,

Microsoft

Presence Centric; A principal must first subscribe to a presentity to send IMs to its instant inbox.

IM centric: A subscriber must send a special kind of IM to subscribe to a presentity.

Our take is that the two models are _equivalent. It's just a matter of language.

Tony Genovese: They have the same boxes, but they are very different.

Sonu: Our take is that this is an implementation detail, not a fundamental issue.

Kretch: I have a small nit -- subscribe could also be fetch.

Keith: I would like to propose an alternate model. There are potentially many kinds of presence. Presence can be seen as a way to talk to someone. You might have a kind of presence for instant messaging, and another kind of presence for telephoning a certain number. You might want to poll the WG on this... Different presences might be different services, not just different status codes (though they might be implemented on the same service).

Vijay: The WG has long been talking about the kind of presence that is useful for IM, not just any kind of presence.

Keith: So the statuses are limited

Vijay: Yes.

Vijay: Is there any kind of proposition for how the req'ts document must change as a result of the discussion of this issue?

Anonymous: Some central entity maintains presence information, which indicates how to get in touch with somebody. There is an initial step which involves publishing presence information which has been glossed over.

Vijay: What is the specific proposition?

Same: The client must register with a presence entity before IM can take place.

Vijay: Let me rephrase this in terms of the model: There is some kind of user agent, for the presentity, which establishes presence, some kind of logging on. And you're saying that this step MUST be followed before any kind of IM can be sent.

Jonathan: I thought we just hummed saying that it is not required to have presence to have IM. Am I insane?

Vijay: That is correct. Let's drop this and go on.

Jonathan: An implementation is perfectly free to require logging on before an IM can be sent. The protocol need not specify that.

What Kind of Status Information Do We Need? -- Mark Day

In the current draft of the requirements document it states:

6.1.3: "The common presence format MUST include a means to represent at least the following STATUS conditions: OPEN/CLOSED, and available/busy/idle".

Should this requirement stand?

Kretch: I was opposed to this before, and the misunderstand was that locations would be fairly static, whereas others would assume that only the ones that are OPEN would be returned. I now understand this requirement and think it's OK.

Larry M: This is a requirement on a schema, not on any particular status message. Why is it not a requirement for the schema to be extensible? It doesn't say that any particular status message contains this information. Does 6.1.5 (extensibility requirement) say that the IETF can extend the presence schema, or that anybody can extend it? Does this already cover 6.1.3?

Vijay: But multiple services might want to interoperate and understand each others presence information, and requirement 6.1.3 results in that.

Mark: Even given the extensibility requirement, 6.1.3 is required for interoperability.

Sugano-san: It seems odd to me that avail/busy/idle is a requirement, as it is not defined.

Tony Genovese: I suggest that you add the text in to say that this requirement say "in order to support presence information for instant messaging..."

Dave M: "If the system is supporting IM, the common presence format must include OPEN/CLOSED." Does the WG support that?

Larry: There seems to be an assumption that there are different categories or schemas for presence, and IM presence is one of those categories, and that the IM presence schema must include this."

Anonymous: There may well be multiple forms of IM, not just one. Status should be associated with an IM address, not just a presence entity, because a presence entity might have multiple IM addresses.

Jonathan R: There is an assumption that there are various means of communicating with me, and for each of those means there is "presence" information. To me, OPEN/CLOSED applies to some kind of msgg inbox, but could apply to all kinds

Lisa proposed: "The protocol/format MUST define a standard way for an IM service to represent availability of an IM identity (associated with the presentity) for instant messaging."

Mark: Too complex.

The WG hummed somewhat in favor of the revised wording of 6.1.3, but there was also opposition.

Josh Cohen: All you need to do is say that the presence service provides presence information via schemas or profiles.

Vijay: We're talking about making a specific schema or profile for IM.

Mark: People need to express crisply what the editors need to do.

Jonathan: When I objected to open/closed, I didn't want to restrict the scope, I wanted to open it to not just IM.

Gordon: The original wording has problems, but it doesn't necessarily say that every presentity must include this, it simply says possible to advertise IM availability.

Gordon: One of the reasons we need presence is to support IM. A req'ts document must acknowledge the places these are depending on each other.

Dave reading Lisa's revised wording: "The WG MUST define a minimum standard presence schema suitable for Instant Messaging services". Do we agree?

Derek & Tony: It should read "any" messaging service.

Tony: If it is possible to define your own schema, then can this schema requirement.

Dave: All in favor of moving this to the IM section?

Medium-loud hum.

Dave: OK. This is part of IM.

Unique-IDs in Instant Messaging

Derek: Unique-IDs should be required, are very useful for debugging.

Anonymous: Threadability is very useful in chatting (in favor).

Another guy: Is it correct to assume you need globally unique message-IDs? This adds the requirement for state.

Eric Rescorla: No, unique IDs don't require state. E.g. message digests.

Pete Resnick: We should define whether debugging and/or message threading are required functionality, not be deciding on implementation.

Mark Day: Pete is correct. I want to say that the threaded-conversation support is one we already discussed and rejected.

Dave M: Are there any arguments against putting threaded-conversation support and debugging support in the requirements?

Larry: "debugging support" is too ambiguous. How about "tracking" of messages: support for tracing messages through the system.

Joe: For debugging, we need to uniquely identify messages and track them through the system.

Tony: The list can decide what level of debugging is needed.

Nick: Or even simpler, "there is a requirement to uniquely distinguish all messages ever."

Vijay: Yes, we should take this to the list: debugging, tracing, and replay detection.

Eric Rescorla: Message-Ids alone are useless replay detection, and debugging doesn't need globally unique IDs. I'm willing to say that....

Vijay: Take it to the list.

Successful Delivery Acknowledgement

Kretch: From the point of view of privacy, it must not be a requirement to ACK whether a message has been received.

Vijay: I hear some arguments for SHOULD rather than MUST on delivery acknowledgement.

Mark: I don't think the hiding/privacy requirement is relevant.

Nick: Let me understand: With a MUST you have either delivered, or failed. With SHOULD, you have more than two states.

Harald: I have a problem with the way you state this. You say the protocol must inform the sender. Does this mean the protocol must/should include a mechanism by which the recipient can inform the sender of success/failure, or that all implementations must always employ this mechanism?

Vijay: This constrains what the protocol must define.

Harald: Then this must be a MUST, because its a bad protocol that doesn't allow errors to be returned.

Jonathan: Just say there must be a way to indicate failure.

Vijay: "The protocol MUST have a way to inform the sender of the failure or success of the INSTANT MESSAGE being sent."

Larry: I think "successful delivery" is a very fuzzy concept, and we struggled with this a lot.

Mark Day: The requirements doc defines "SUCCESFUL DELIVERY" very closely.

Larry: Then I'm unhappy to exclude other kinds of successful delivery such as "the user has seen this".

Vijay: If you have thoughts of other responses, get them out on the list.

John Noerenberg: It seems the word "capable" is merely missing here.

Nick S: We're talking about "instant messaging". There's a tendency in the room to only hear "messaging". Instant messaging is very dynamic, and we have to keep focused on that.

John Stracke: There should be a 7.2.2: the sender should have a way of specifying whether or not they want a response.

Dave: OK, lets hold that a moment.

"The protocol MUST be capable of informing the sender of the SUCCESSFUL DELIVERY of the INSTANT MESSAGE or reasons for failure."

SMTP

The WG agreed that using SMTP as a basis for IM/PI is NOT a requirement.

Further Discussion

Colin Benson: Many things were relegated to the list. How will this affect the schedule?

Vijay: I think the things delegated to the list are capable of being decided on the list.

Dave: I think within a few weeks of discussion on the mailing list, Vijay & I will be comfortable submitting a last call. Stay tuned on the list.

Vijay: As those who have been around for a while remember, we were originally supposed to design a protocol, but the WG ended up being chartered only to define requirements. We would like to bring back our original charter for the purpose of re-chartering the group, changing dates of course.

Dave: The charter originally asked for a transport protocol, a PI protocol, and an IM protocol, which could be the same thing.

Josh Cohen: I don't think you should do this at all. Once the req'ts doc is done and reviewed, that may completely change your charter. Focus on req'ts, not on charter.

Vijay: Anything else? If nothing else, maybe we're done.

Dave: Any other open issues on the requirements doc?

Josh Cohen: I do think you should have a target date for submitting the requirements doc. Are you having a WG last call now, meaning that in a couple weeks you will have an IETF last call?

Dave: I'm hoping the issues relegated to the list can be resolved in a couple weeks, at which point we're prepared to shut down unfruitful comments.

Klaus: Anonymous subscriptions and authentication: We have the spamming problem in SMTP. I'm afraid that we get the same problem if we do not require authentication, and if we allow for anonymous subscriptions and messages.

Vijay: You will take this up on the list?

Kretch: I remember there was discussion of "block" list, which could for an individual user block anonymous senders.

Tony: I'd like to see the PI and IM as two separate documents.

Vijay: OK, that's all.

Slides

None received.