2.1.3 Instant Messaging and Presence Protocol (impp)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Mark Day <markday@cisco.com>
Leslie Daigle <leslie@thinkingcat.com>

Applications Area Director(s):

Ned Freed <ned.freed@mrochek.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.

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:

Done

  

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

Done

  

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

Feb 01

  

Submit I-D on common instant message format

Mar 01

  

Meet at 50th IETF in Minneapolis

Apr 01

  

Submit Common Presence and Instant Messaging document and Common Instant Message Format to IETF for consideration as Proposed Standard

May 01

  

Upon publication of RFCs, close group.

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2778

 

A Model for Presence and Instant Messaging

RFC2779

 

Instant Messaging / Presence Protocol Requirements

Current Meeting Report

IMPP -- Instant Messaging and Presence Protocol
51st IETF, London, England
August 8, 2001.
Chairs: Mark Day (MD), Leslie Daigle (LD)
Minutes: Robert Sparks

Meeting plan:
. overview of open issues
. review of the PIDF presence format proposal
. gateway walkthrough reports

Open Issue: SRV format
----------

No discussion, no objections for proposed consensus for "poking and trying"

Open Issue: Fetch/Subscribe
----------

Jonathan Rosenberg (JR): don't want to special case zero.

A fetch is a zero-length subscribe and unsubscribe is subscribe w/ expire 0

(Discussion reinforced that we don't have a subscription id in cpim.)

Edwin Aoki (EA): ends up with extra notify that you might not have wanted

LD: Subscribe 0 gets a notify - still room for unsubscribe which has same effect with no notify

Dave Crocker (DC): Shouldn't have two ways to unsubscribe

Much discussion about the extra notify.

Patrik: how are you going to deal with DoS specifying people get unwanted notifies.

John Stracke (JS): not sure subscribe 0 to existing sub means a notify happens

EA: extra notify is expensive.

DC: If notifies are expensive, DoS is a real issue

Lawrence Conroy (LC): pint had an explicit unsubscribe.

Athanassios Diacakis (AD): really sees sub/0 and unsub as different operations

DC: extra complexity provides opportunity for extra bugs

LD: (brought up the multiple subscription issue)

Dave Oran: Unsubscribe and Sub/0 have different error characteristics

LD: This has been unclosable too long - how do we close?

JR / DC : We compromise...

LD: we are about to remove unsubscribe from CPIM - is that OK?
Hum: strong

Discussion moved to discussing multiple subscriptions.

JR feels strongly that we need a subscription identifier

AD : I no longer object to multiple subscriptions to the same id

Room generally agreed that we needed a subscription identifier

AD: Can we clarify new subscribes to the same id and subscription id fails only if there is a pending transaction

JR: Do we have consensus that Fetch is now a sub/0 with a new sub id?
Hum: Strong

AD: Need to be very clear when drafting difference between Subscribe / Fetch / Unsubscribe

Open Issue : CPIM success/refused/failure messages : support for polite
----------
blocking

JR: should say nothing or very little

AD: cpim is already pretty clear

Answer: non-issue, already covered in drafts

Open Issue : IM use of message/cpim
----------

Concurrence that we update draft to specify use

Open Issue : Handling unwanted notifications
----------

LD: is this cpim or an individual protocol problem? I think it belongs to the individual protocols.

Patrik: Agrees, but there should be direction given to those groups in the cpim draft.

Review of CPIM-PIDF
------------------
MD: Not sure a presence deliverable is in our mandate (not explicitly in charter) Do we take the current individual draft as a wg item?

Hiroyasu Sugano (( presentation on draft))

Theodore Havinis (TH): 3GPP doesn't understand why contact address is optional. Was planning to use it as an identifier for selecting tuples. Wants some identifier he can use.

JR: Willing to compromise position on metadata as long as the fundamental data stays in the presence data itself.

DC: Work will not be useful unless we change our focus to stripping things out instead of putting small new nice things in.

JR: Finishing is most important.

MD: Question is do we take this draft as a start, take something else, or step away and not specify anything

Andrew Z? (AZ) : Need a concrete simple thing to start from.

MD: Do we accept this document as a work item.
Hum: Strong

LD: General comments? Do we start with format questions or the metadata question?

Graham Klyne (GK): Most important to focus on the core presence tuples now.

JR: Should just adopt 2778's tuple definitions - when we have bijection we're done

AD: We aren't using 2778 as a start point though

EA: Would we be done if required the name in each tuple to be the pres URL?

MD/TH: Pure bijection will fall short - 2778 is missing things

GK: We stop when we have what 2778 requires plus what's required to have a working protocol.

MD: Is there agreement on that characterization?
Hum : Strong

JR: Extensibility is one of the things that will be required to make the protocol work.

Nick Shelness: Is xml extensibility enough? There may be issues with things like binary valued attributes.

DC: Extensibility discussions should be limited to specific known deficiencies.

EA: markup for the person/presentity (as opposed to the tuples) is something different and doesn't belong here.

MD: mapping of tuple to communication point is a fine mapping, but not necessarily the only valid one.

AZ: Maybe we could have classes of tuples (device classes), and markup for those classes

GK: On the internet, no one knows you're a dog. Someone will come along and find a different mapping.

MD: Next question is do we use just XML or XML and metadata (message/cpim format vs XML directly)

GK: Start working from what's in draft.

JR: Reinforces that presentity URL must appear in the presence document.

HS: Agrees with JDR.

JR: Not clear if From represents user or server. Not clear what From means.

Gatewaying Walkthrough Report
-----------------------------

Sathya Narayanan presented PRIM-CPIM walkthrough.
((presentation PRIM-CPIM walkthrough))

MD : Need to build a more detailed report showing error conditions

Jonathan Rosenberg presented SIMPLE-CPIM walkthough.
((presentation SIMPLE-CPIM walkthrough))

JR : Also need to add failure cases

JR: Not sure how pres: urls are going to map to protocols specific URLs.

GK: pres: url should be preserved in payload

Conversation led to agreement that a gateway converts a pres URL based on secret knowledge. (Do what email gateways do).

Patrik: AD view is that specification of how individual protocols map to CPIM belongs in individual groups, not in IMPP. This should show up as a separate document that talks about gatewaying.

Close
-----

LD: We've reached some kind of closure on all major points; really hope this will have been the last IMPP meeting (i.e., that we can wrap this into revised & finished documents before the next IETF).

Slides

CPIM Presence Data Format