Last Modified: 2004-02-02
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. Included might be 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. Each of these mechanisms will be consistent with a SIP-based architecture, as well as meeting the constraints otherwise described in this charter.
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.
Done | Submission of event package for presence to IESG for publication as Proposed Standard | |
Done | Submission of watcher information drafts to IESG for publication as Proposed Standards | |
Done | Submission of proposed event list mechanism to the SIP working group | |
Jun 03 | Submission of requirements for event publishing to the IESG for publication as Proposed Standard | |
Jun 03 | Submission of presencelist auth/modify requirements draft to IESG for publication as Informational | |
Done | Submission of proposed mechanism for event publishing to the SIP working group | |
Jun 03 | Submission of requirements for presence partial notification and filtering to the IESG for publication as Informational | |
Jul 03 | Submission of CPIM mapping draft to IESG for publication as Informational | |
Jul 03 | Submission of instant messaging session drafts to IESG for publication as Proposed Standards | |
Jul 03 | Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard | |
Jul 03 | Submission of advanced messaging requirements draft to IESG for publication as Informational | |
Jul 03 | Submission of presencelist auth/modify mechanism drafts to IESG for publication as Proposed Standard | |
Aug 03 | Submission of proposed mechnisms meeting the advanced messaging requirements to the IESG or appropriate working group | |
Sep 03 | Submission of Presence/IM System Architecture draft to IESG for publication as Informational |
Minutes, SIMPLE Working Group, IETF 59 recorded by Dean Willis Monday, 1 March, 2004 1930 GMT+9 Meeting called to order by Robert Sparks. "Note Well" slide presented. Agenda accepted as presented. Topic: Status by Chairs Slides presented reviewing current status. ------------------------------------------------------------------------ Topic: RPIDs, Henning Schulzrinne Slides presented review status and open issues. Issue: Extension namespace model. PIDF calls for one namespace ("status") for all extensions as top-level elements. Do we define extenions from RPID as top-level elements in this namespace, or extend from other namespaces? namespace model discussed at some length . . . This MAY be an error in the PIDF documents, and Jon Peterson will examine them and see if something is needed there. Issue: CIPID e SIMPLE XCAP Tutorial Led by Jonathan Rosenberg Notes by Dean Willis March 4, 2004 1300 GMT +9 Gardenia Room, Lotte Hotel, Seoul, ROK The purpose of these notes is NOT to document the tutorial, but to record any working-group related decisions that might arise during this meeting. Slides are at: http://www.jdrosen.net/papers/xcap-tutorial.ppt ToDo list: 1) We need to make sure that the preservation of client-provided namespace prefixes is declared as a MUST level in the XCAP specification. 2) Check up selecting attribute in xcap when value is escaped -- does the return value contain the literal? 3) Clarify XCAP spec on selection behavior when there is partial repetition on the attributes -- for example, when the query specifies attr="2" and there are two difeerent records having this attribute but varying in other attributes. 4) There appears to be an unhandled case where the application validating the xcap document finds that the document is invalid. The XCAP server already returned a 200OK to the client, but the application has decided to reject the new document. How does the client know? 5) Investigate the possibility of returning a 306 redirect from HTTP requests so that you can be redirected into a quota-controlled space. If possibly, needs to be clearly said in XCAP. 6) Clarify discussion of filename extensions question. 7) Talk about escaping in document (see #1). 8) Document If-None-Match * etag matching to make sure that attempts to overwrite an existing document don't create a new resource. Also document return codes for differentiating the two cases ex-post-facto. 9) Clarify that ordering of schema and existence both impact insertion placement. 10) Clarify use of positional parameters to add repetitive elements and interaction of repetitive elements on selection. 11) Look at WebDAV 409 generic error body return and see if we can reuse it. |