Current Meeting Report
Jabber Logs

2.1.5 Instant Messaging and Presence Protocol (impp)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: -- Additional IMPP PAGE
NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 06/07/2002

Mark Day <>
Derek Atkins <>
Applications Area Director(s):
Ned Freed <>
Patrik Faltstrom <>
Applications Area Advisor:
Patrik Faltstrom <>
Mailing Lists:
General Discussion:
To Subscribe:
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:
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
Done  Submit I-D on common instant message format
Done  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.
  • - draft-ietf-impp-cpim-03.txt
  • - draft-ietf-impp-cpim-msgfmt-06.txt
  • - draft-ietf-impp-cpim-pidf-05.txt
  • Request For Comments:
    RFC2779 I Instant Messaging / Presence Protocol Requirements
    RFC2778 I A Model for Presence and Instant Messaging
    RFC3339 PS Date and Time on the Internet: Timestamps

    Current Meeting Report

    IMPP - 11/18 19:30 - IETF55
    Chairs: Mark Day, Derek Atkins
    Agenda Bashing (no bashing)
    Current Draft Status (no comments/questions)
    Floor comment:
    PIDF issue - Jonathan Rosenberg - would like to change PIDF to allow zero 
    tuples. Will take request to mailing list.
    CPIM changes (Jon Peterson)
     (document split into three)
     (open issues: loop detection, notification acknowledgement)
    Jon - Does anyone here think e-e for IM services across gateways should be 
    absolutely mandatory?
    Mark - we don't need to make people go to the mike immediately
    Discussion on Loop Detection:
    Jonathan Rosenberg - would be catastrophic to have a protocol without it.
    John Ramsdell - Would need this for NOTIFY as well
    Discussion on Notification Acknowledgement:
    (Is TransID useful in notification?)
    Thanos - TransID is useful for detecting duplicates
    John - Could detect duplicates with timestamps
    Jon - Timestamps are optional
    (Should we also have SubscripID?)
    Mark - Can't include things because it's easy - must have a 
    compelling reason. For SubscripID, that's being able to associate 
    notification with subscription.  This also argues against keeping 
    Jon - Transport could take care of duplicate detection
    Thanos - Taking TransID out makes mapping to concrete protocols 
    Thanos - Isn't the real issue whether or not Subscriptions need a 
    transaction ID
    (seems to be consensus around adding SubscripID, some discussion about 
    keeping TransID, Discussion seemed to conclude that TransID could be 
    replaced with SubscripID)
    Other Issues?
    Thanos - Why not take some of the IM specific 2779 features out of PIDF. 
    Make the IM things inside PIDF and make them a separate profile of PIDF.
    (Short discussion seemed to be favorable)
    Pekka - Do we need to include a NAPTR resolution instead of just SRV?
    (notetaker note : I'm not sure I figured out Pekka's question 
    Jon/Jonathan - the motivations for NAPTR in SIP don't apply to what we're 
    doing in CPIM. Stick with what we have,
    Pekka - use of SRV is broken/insufficiently specified
    Mark - would it be sufficient to more clearly specify what to do with the 
    result of an SRV lookup?
    (Discussion Pekka/Jon seemed to agree)
    Jonathan - What we have now isn't broken but it should be more explicit 
    about using the resolution mechanisms of the underlying concrete 
    Dave - What is the real problem being addressed?  (Discussion 
    answered:  what do you do with an IM URI when you have more than one 
    choice of stack protocols to use to use it.)
    (Resoulution of im: to something protocol specific belongs to that 
    specific protocol once the protocol has been chosen)
    Mark - Having just an IP address and port is not enough though - what 
    needs to go into the cpim document to make it sufficient?
    (Discussion of whether the SRV mechanism is for finding endpoints or 
    gateways. Discussion resolved that it's always finding endpoints
     - gateways are responsible for knowing that they're gateways).
    Mark - Is everyone comfortable with what the SRV draft is attempting to do? 
    (Jon believes he understands what the draft needs to do - the change is not 
    to mechanism, it is adding descriptions of what to do with the result of the 
    Jonathan - need to be sure that all cpim realizations can carry literal 
    pres:/im: URIs - otherwise we find ourselves in NAPTR space.
    (Discussion of the current mechanism ensued - resolution was that it was OK, 
    Jon is still comfortable with what to do - adding discussion of what to do 
    with the result of an SRV lookup. Mark/Jon verified that the revision of the 
    draft needs to capture Jonathan's above point.)
    John - Need to address 5.1.12 (2779) - How do you authenticate a 
    subscriber across a cpim membrane?
    Jon - Subscription is different from IM and Notification. 
    Identification for subscriptions can be achieved through transitive 
    Jonathan - We've addressed this question multiple (4+) times. Do we have any 
    new information that warrants reopening it. (John said no).