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
Mark Day <firstname.lastname@example.org>
Leslie Daigle <email@example.com>
Ned Freed <firstname.lastname@example.org>
Patrik Faltstrom <email@example.com>
Patrik Faltstrom <firstname.lastname@example.org>
To Subscribe: email@example.com
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:
- INSTANT MESSAGING
- ACCESS CONTROL
The working group plans to deliver the following document:
- Requirements for Instant Messaging and Presence
Submit Internet-Draft of Design Goals for Instant Messaging and Presence Information
Submit design goals Internet-Draft to IESG for publication as an RFC
Submit I-D on common instant message format
Meet at 50th IETF in Minneapolis
Submit Common Presence and Instant Messaging document and Common Instant Message Format to IETF for consideration as Proposed Standard
Upon publication of RFCs, close group.
· A Common Profile for Instant Messaging (CPIM)<!999999>
· Common Presence and Instant Messaging Message Format<!999999>
· Date and Time on the Internet: Timestamps<!999999>
A Model for Presence and Instant Messaging
Instant Messaging / Presence Protocol Requirements
IMPP -- Instant Messaging and Presence Protocol
51st IETF, London, England
August 8, 2001.
Chairs: Mark Day (MD), Leslie Daigle (LD)
Minutes: Robert Sparks
. 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?
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?
AD: Need to be very clear when drafting difference between Subscribe / Fetch / Unsubscribe
Open Issue : CPIM success/refused/failure messages : support for polite
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.
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.
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).
CPIM Presence Data Format