Last Modifield: 06/07/2002
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
| 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. |
| RFC | Status | Title |
|---|---|---|
| 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 |
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 TransID. Jon - Transport could take care of duplicate detection Thanos - Taking TransID out makes mapping to concrete protocols fuzzier. 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? --issue-- 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) --issue-- 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 correctly) 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 protocols. 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 lookup). 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.) --issue-- 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 authentication. Jonathan - We've addressed this question multiple (4+) times. Do we have any new information that warrants reopening it. (John said no). |