Current Meeting Report
Slides


2.1.3 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:

       http://www.imppwg.org -- Additional IMPP PAGE
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 06/07/2002

Chair(s):
Mark Day <markday@cisco.com>
Derek Atkins <derek@ihtfp.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
P. Faltstrom <paf@cisco.com>
Applications Area Advisor:
P. 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
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.
Internet-Drafts:
  • - draft-ietf-impp-cpim-msgfmt-06.txt
  • - draft-ietf-impp-datetime-05.txt
  • - draft-ietf-impp-cpim-pidf-05.txt
  • Request For Comments:
    RFCStatusTitle
    RFC2778 I A Model for Presence and Instant Messaging
    RFC2779 I Instant Messaging / Presence Protocol Requirements

    Current Meeting Report

    IMPP WG Notes
    2002-07-18
    54th IETF, Yokohama
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 8bit

    Agenda no items added

    IMPP Status
    - The datetime draft has gone to auth48
    - MSGFormat is in WG last call

    PIDF update
    By Hiroyasu Sugano

    The current draft is 05, and is deemed sufficiently stable. The suggestions made in Minneapolis have been integrated, including the agreed minimalist approach.
    - Defines new media type for application/cpim-pidf+xml and new XML namespace urn:ietf:params:xml:ns:cpim-pidf.
    - XML namespace is for both status value extensions and other tag extensions.
    - XML Schema replaced use of DTD
    - Recommendations from RFC3023, IETF XML guideline and other sources have been followed.
    - Only two presence states defined: open (available) and closed (unavailable). Other states like busy or away must be defined by developers or applications using PIDF.

    Comments at the microphone:
    Jonathan Rosenberg suggested adding a reference to the actual schema.

    Graham Klyne pointed out the datetime draft has a couple of edits to handle case sensitivity issues. These edits should be compatible with XML schema as well.

    Conclusion: PIDF is ready for last call. No objections were raised.

    CPIM
    Mark Day

    Goal of today: CPIM needs a specific list of issues in order to mature CPIM to the same level as PIDF and bring it to last call. Is the proposal adequate? What needs to change?
    Deadlines must be established. Are there people with substantial concerns about CPIM?

    No issues were raised at the microphone (beyond the known item next on the agenda, that of authenticated notifications and subscriptions)

    Jon Peterson volunteered to create the next CPIM draft by next Friday.

    Authenticated notifications and subscriptions
    Mark Day

    The IMPP charter still says that IMPP is supposed to solve all problems in instant messaging and presence. For a while, the chairs have been operating under the de facto charter of delivering message-format, CPIM and PIDF. Should the WG be officially limited to this workload? Should the workload be extended, given that the charter theoretically allows it?

    Jonathan Rosenberg opposed taking on this work item. The minimalist approach has been working and allowed us to make progress. This is not a trivial work item. Security isn’t unimportant, but it’s very hard to solve without the context of the actual protocol. I don’t think we should define a subscription format, nor do I think we should expand the scope of the existing work. I think that would mostly amount to choosing S-MIME, I don’t know if it’s more than that.

    Derek Atkins explained that there would need to be a line in the notification that has the name of the presence server which is the author of the notification. This is the only change required.

    Mark Day asked whether we need a way to identify the server, as well as the presentity. Currently only the presentity can be identified. In hop-by-hop mode, don’t you care about the server before you?

    Jonathan: We’re all about doing end-to-end, which specifically ignores the hops. Subscriptions are generated by end users, and in many cases end-users will not have public keys. Authenticating them to the destination server across boundaries is a very hard problem. Simple has been grappling with transitive models and other models. I don’t think it’s worthwhile to pursue supporting authenticated subscriptions. It doesn’t make sense to delay completing a group for something that can’t be deployed well.

    Sean Olsen seconded Jonathan’s statements. Neither subscription nor notification should be tackled at all. These are not problems that can be tackled easily or within a reasonable time-frame.

    Graham Klyne: Why is the server generating a notification not covered in the signature?

    Derek: Currently we have the from and the signature is supposed to match. However, it’s not clear *what* the signature is to be matched to.

    Jon Peterson: This issue is part of the work items that I’ve just taken on, in editing CPIM. I think the work item covers what we need.

    Sean Olsen: You do mean service, and not server? A signature of a service is very different from a signature of a server.

    Zmolek said that none of the issues 6, 7 or 8 from http://impp.fujitsulabs.com/ml-archive/IMPP-WG/200206/msg00012.html should be taken on.

    Jon Peterson: I have no objection to trying to tackle these problems, after we do the work we are currently doing. These are interesting problems but difficult.

    Graham Klyne: If the scope is to be expanded, I think there needs to be a fairly compelling case to do so.

    Zmolek: I’d also be supportive of such an effort, but not here and now.

    Derek I agree getting CPIM out the door is important, but a simple wrapper for presence information to identify the presence service is a one line change. (#7 from above referenced msg)

    Jon Peterson: What value does that service identifier add, assuming we’re not doing signed subscription requests?

    Rohan Mahy and Graham Klyne: Let’s get proposed text, and discuss it on the list.

    Jonathan Rosenberg: What does it mean to have a wrapper? It’s only a XML document. By wrapper for service identification, how is this different from the signature identified in the certificate associated with the notification?

    Mark Day proposed taking the resolution of this service identification issue to the list. Derek will send mail to John ASAP. If there’s still silence on the matter within a week, we can probably not worry about it at least as far as the next draft revision goes.

    Derek Atkins asked for new discussion. After we get CPIM out the door, should IMPP as a WG accept the work item of doing signed subscriptions and notifications?

    Jonathan Rosenberg suggested that the WG answer that question later to see how other things shape up. There might be other things that people want to do, and deployment might contribute unforeseen work items.

    Slides

    None received.