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
Vijay Saraswat <vijay@saraswat.org>
Florencio Mazzoldi <flo@networkprojects.com>
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Patrik Faltstrom <paf@cisco.com>
General Discussion:prim@ml.fujitsulabs.com
To Subscribe: majordomo@ml.fujitsulabs.com
In Body: subscribe prim (your-mail-address)
Archive: http://www.imppwg.org/prim/ml-archive/
The purpose of this working group is to produce a set of protocols for Presence and Instant Messaging services, which will minimally satisfy the IMPP Model and Requirements [RFC2778/2779]. In June 2000 the IMPP WG produced various Internet-Drafts with several protocols falling in the same group due to very similar architectures. Four of those proposals were combined into a new one called PRIM (Presence and Instant Messaging) following the WG chairs recommendation to proceed with proposals from that group. The PRIM working group emerged from this collaborative activity.
The working group will generate a set of standard track documents for the PRIM specifications. It will specify the protocols and data formats for the Presence and Instant Messaging services using a minimalist approach, complying with RFC 2779 and with CPIM, without adding implementation complexities. BCP 41 will be the basis for working group consideration of the transport implications of the PRIM designs with respect to network congestion
These protocols will take existing architecture and widely-deployed Presence and Instant Messaging services on the Internet as an intra- domain basis, and use CPIM over TCP for inter-domain exchange of presence information and instant messages.
The working group will work in collaboration with the IMPP WG to finish the CPIM specifications.
The PRIM specification documents will include the following:
o The inter-domain server-server protocol specification for the Presence/Instant Messaging services, which map the CPIM specification being developed by the IMPP working group over TCP. This specification defines protocols for subscription/notification and instant messaging.
o The client-server protocol specification for the Presence service. This specification defines a protocol to subscribe to a presence entity (presentity), to send a change notification to a watcher, and to control the presentity and presence information distribution.
o The client-server protocol specification for the Instant Messaging service. This specification defines a protocol to send and receive instant messages between a client and a server.
The PRIM proposal (draft-mazzoldi-prim-impp-01.txt) will serve as the starting point for the discussions in this WG.
Sep 01 |
|
Submit a set of revised specifications to IESG for consideration as standard-track RFCs, subject to CPIM completion of relevant milestones. |
Dec 01 |
|
Review work items and re-charter |
Presence and Instant Messaging Protocol WG (prim)
Tuesday, August 07 1300-1400
===============================
CHAIR: Vijay Saraswat (vijay@saraswat.org)
Minutes: Athanassios Diacakis (thanos@personity.com)
AGENDA:
. Agenda Bashing
. Current Status of PRIM activity
. Revisions in the latest draft
. Open Issues
. Closing
MINUTES:
Vijay presents agenda
- No suggestions for agenda changes
Vijay presents charter of PRIM & current status
- Dates might slip because WG was only just chartered
- Mailing lists have had some problems; volunteers to host mailing list
Sugano presents most recent revisions
- Document re-organization
+ Base commands and control commands
+ Separation of commands to Presence, IM and Common
Comment: Better off with two documents, one for server-server and one for client server.
Vijay: Yes, this is an open issue. Will discuss later in the meeting.
- Server-Server Authentication
- Tweak in versioning style, made more similar to HTTP
- Introduction of "default class". Watchers that are not defined in the classtable are added to default class ".".
Open Issues
- CPIM Aligmnent
+ Address resolution methods
Aoki: Shouldn't it be _pr._prim instead of _prim-im
+ Subscribe/Fetch behavior
+ Cancel subscription
Comment: Introducing server-)server command that is not in CPIM will not do much good.
Rosenberg: CPIM is minimum, can do extra. SIMPLE can use notification with Expiration of 0 to indicate expired subscription.
- Reduction of number of notifications
+ PUBLISH sends one tuple, NOTIFY sends whole data
Two solutions: publish more that one tuples at the same time, or restrain notification frequency.
Aoki: Is a PRIM gateway unable to publish partial data unless is keeps state?
Vijay: Yes, with current spec. This is IMPP issue.
- Login time subscriptions
+ Solution 1: Issue them at login time has problem that large number of buddies will cause overhead
+ Solution 2: Server stored buddy list and provide synch mechanism.
Vijay: This is what most commercial implementations use.
Any reasons not to go with number 2?
Comment: Subscriptions are user specific not client specific and thus current implementations go with #2.
Vijay: One document or two documents?
Comment: Two documents so we can make progress on server-)server
Show of hands: many for splitting, none against.