Last Modifield: 07/26/2002
The primary work of this group will be to generate: 1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779, CPIM and in BCP 41 (so that the transport implications of the extension with respect to network congestion are considered in the design).
2. A proposed standard SIP event package and any related protocol mechanisms used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM.
3. An architecture for the implementation of a traditional buddylist- based instant messaging and presence application with SIP, including for example new mechanisms for message confirmation delivery, indications for when a party is in the process of typing a message, secure buddylist manipulation operations, and the extension of the CPIM presence format to describe typical IM states.
All SIMPLE proposals fulfilling these goals must document the mappings of their operation to CPIM. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions.
The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here.
The working group will operate in close cooperation with the IMPP working group, which will be completing CPIM in parallel. The working group will also cooperate with any other groups defined to standardize other presence and IM systems, to ensure maximum sharing of information and avoid reinvention of the wheel. The working group will cooperate with the SIP working group, soliciting reviews to ensure its extensions meet SIPs requirements. The working group will also collaborate with the SIP WG to ensure consistent operation of the SUBSCRIBE and NOTIFY methods across the other applications being defined for its use.
|JUL 02||Submission of CPIM mapping draft to IESG for publication as Informational|
|AUG 02||Submission of presence list package set to IESG for publication as Proposed Standards|
|AUG 02||Submission of instant messaging session drafts to IESG for publication as Proposed Standards|
|AUG 02||Submission of presence list auth/modify requirements draft to IESG for publication as Informational|
|SEP 02||Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard|
|SEP 02||Submission of advanced messaging requirements draft to IESG for publication as Informational|
|OCT 02||Submission of Presence/IM System Architecture draft to IESG for publication as Informational|
Minutes, SIMPLE WG, IETF 55 11/18/2002 1530-1730 Atlanta, Georgia US Reported by Dean Willis Edited by Robert Sparks Blue sheets: circulated with some discussion of algorithm, one from the back right and one from the left front. Agenda discussion: No issues raised. Status discussion: Chairs ------------------------- MESSAGE has an RFC number. Presence event package has passed WGLC and is in IESG. Charter requires date adjustment. Open question: Do we need a new charter item for PUBLISH? Suggestion from audience that this be handled most expeditiously. The chair reported a consensus to adopt the PUBLISH requirements into the chartered work of the group. Publish Work: Sean Olson ------------------------- Changes in the -01 model, now 3 pieces of information: class, instance or stream header, facet which indicates target group or set of logic that applies. Publication class defines a type. Open issue, should this be mandatory?. Publication facet defines intended watcher group. Open issue: Is the syntax sufficiently flexible? Should this be standardized? Publication Instance provides source identification. Open issues: Should there be an explicit dialog? Is the proposed syntax adequate? Several general open issues raised in slides. Proposal: We should move to an explicit dialog model. We don't do this in REGISTER for historical reasons, and this has caused a mess. It is nice to have an identifier that is persistent across transactions. There are also requirements for name persistence that extend well beyond a dialog, and this is a seperable problem that the authors propose to move to a seperate draft. Question: Why are things like the publication class seperate headers instead of body elements? Short answer is that this requires MIME/MULTIPART automatically. Question: If we solve the greater naming problem, do we still need a dialog? Consensus: yes. Comment that stuff in headers is metadata, understandable by a compositor even when the body isn't. Publish work: Aki Niemi ------------------------ Proposes a general framework based on the Olson work. Provides new "Allow" header functionality for publication operations. Open questions on payload format. Open questions: abandon, integrate with Olson, complete in seperate track? Discussion: Publication is really an inherent part of the 3265 events package, it's just getting done later. There seem to be no real conflicts between header use in this work and in 3265. PUBLISH will want to say that future event packages should include details of publication. Further discussion: There may be more semantic analysis of what we mean by "allow/supported" headers here. Poll: Should requirements document for PUBLISH be a working group effort? Proposal that we do requirements here and draft up a solution for handoff to SIP. 3GPP Messaging Requirements Draft: Aki Niemi -------------------------------------------- Includes data manipulation and privacy requirements that go beyond current SIMPLE work. Data manipulation has much in common with conference work in SIPPING and author proposes moving this work there. There are open issues on addressing and message class based diversion, and on charging and security. Author assumes that charging and security fall into the regular work. Question: What do you mean by message class? Answer: We're not sure. It means something like "advertisement" or "personal" or something like that. Question: Is this in e-mail. 3GPP Presence Requirements: Kristian Kizs ----------------------------------------- Require standardized publication mechanism, publishing from multiple PUAs, feedback on publishing and composition, and efficient publishing of large multimedia content including partial publication. Several issues with filtering and efficiency described in slides. Question: Process: Can this be an informational seperate draft, or should this be in the main requirments body deferred to later discussion. Comment on efficiency issue: In some off-list discussions in came up that much of the large-media stuff can be addressed with content indirection. Further requirements on presence document, authorization, and presencelist given in slides. Comment on work process: There really aren't any other requirements documents to integrate this work into. Do we need one? Can we take the requirements out of here and merge them into other work that is going to include them? Chairs deferred this discussion to the list, along with a request for people to lead on various task points. SIMPLE PIDF Extensions: Paul Kyzivat ------------------------------------ Purpose is to represent SIP-specific features in presence documents. Work spans both the kyzivat (rqmts) and lonnfors (response to rqmts) prescaps documents. Work is based on callerprefs. Proposes a set of requirments discussed in slides. Open question on work process: Enhance these drafts, or seperate into other extensions. Discussion: The discussion of capability registration is similar to other work in ENUM and elsewhere. The whole idea about pushing capability awareness to an endpoint is to allow the endpoint to make an informed decision about whether to attempt communications. Point: This doesn't replace registration. This is on the "other side" of the AOR -- what capabilities does the AOR, not the Contact, support? Generally this is some sort of union of the contact capabilities. Ample discussion followed. Proposal from chair: We go ahead an adopt this is a starting point for the charter item of PIDF extension, emphasizing status appropriate for instant messaging. question: Which of the two referenced drafts are you talking about? Chair response: both: you authors coordinate and go forward. Further discussion deferred to list. Event List Template Open Issues: Adam Roach ------------------------------------------- Issue: mixed vs parallel multiparts? Issue: Metadata, using MIME preamble vs body-part headers. Would a seperate body part be more useful? Do we aggregate meta-data? Discussion: Option 2 (slides) preferred for nesting models by several speakers. Issue: Uniform depth. As defined, subscriptions may require uniform depths in their heirarchy. Does this justify further work? Discussion: This requirements seems to be a headache. If we ever need to include a list from another domain it causes some challenges. This may not happen due to the implicit requirement of understanding an event to subscribe to it? Comment: Experience from LDAP and WebDAV indicates that we will have to deal with recursion eventually, so we might as well solve it now. Data Manipulation Requirements Issues: Jonathan Rosenberg --------------------------------------------------------- Open issues: 1) Security requirements, 2) scope, 3) tuple naming Question: To what degree does this relate to filtering: Answer: Anything that can go in a filter should be subject to policy. Question: We could possibly define a scripting language for this but anything else seems to be insuffient to express policy. Proposal is to remove the scripting discussion as it is implementation, not requirements. Hopefully we can narrow the requirements sufficiently to have choices for the implementation. SIMPLE List Manipulation Semantics: Markus Isomaki -------------------------------------------------- Premise: We see lots of unordered URI lists in SIMPLE applications. A common manipulation mechanism would be very useful. Rather than defining an implementation, the current work defines the semantics requirements of an implemementation. Open issues: scope (presence only, generic list and auth policy, or general purpose data manipulation), plan, synch model, deciding how to choose actual protocols. Discussion of scope and unification followed. One of the main discussion themes was semantic nature of data and discussion of access control policy language being done in other SDOs. Further discussion deferred to list. Message Sessions: Ben Campbell ------------------------------ Three drafts in the discussion -- SDP descriptions, CPIM/TCP, and Jabber sessions. Discussion will focus on first two drafts. Open Issue: Supporting Intermediaries. How much do we want to say? Discussion: We should show cases one zero, one, and more than one intermediary. Discussion: There are basically two approaches: back-to-back media relays, and something on a globally unique name end to end using something like preloaded routes. Discussion: This is a big change from what we have been doing with messaging sessions. Should we vote on it or something? Comment: There seems to be general agreement on using SDP style negotiation. Discussion: Much of what is in cpim is constant over a session, so we should be able to negotiate these up front, perhaps parameterizing them, and then reuse them. This probably requires a CPIM extension registry. Issue: Do we want RFC 1893 and 1894 type confirmations? Suggestion that the delivery reports stuff be pulled out and moved to a seperate documemt. No objections raised to suggestion. Issue: Session keys vs S/MIME. Discussion: S/MIME can use a session key using a shared secret in the SDP. Rohan will work with S/MIME group on this and report back. Note that this applies for encrypted but not signed data. Is Mikey appropriate? General consensus seems to be "not at this time". However, there is a lot of convergence in security going on now, so we can probably defer safely. Issue: M-line format. Three alternatives. Discussion: CPIM/TCP is not a valid token in SDP, no slashes allowed. Further work on SDP format is required. Issue: Comedia usage. COMEDIA makes connection sharing difficult by making it difficult to demux shared connections. Current plan is to get COMEDIA fixed in MMUSIC and then import. If it doesn't get fixed, then we'll have to come up with something else. Question: How do people feel about the work of the design team? Poll: adopt draft-campbell-simple-im-sessions as WG effort, approved by hum, no dissent. Poll adopt cpim-sessions draft as WG effort, approved by hum with several dissenters. Discussion on Jabber-sessions draft: Question: Do we deal with new transports my extending SDP name space, or is there a way to do it using the MIME registry? Suggestion that this should be followed up in the SDP draft.