Current Meeting Report
Jabber Logs

2.1.13 SIP for Instant Messaging and Presence Leveraging Extensions (simple)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 07/26/2002

Robert Sparks <>
J. Peterson <>
Applications Area Director(s):
Ned Freed <>
Patrik Faltstrom <>
Applications Area Advisor:
Patrik Faltstrom <>
Mailing Lists:
General Discussion:
To Subscribe:
Description of Working Group:
This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard.

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.

Goals and Milestones:
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
  • - draft-ietf-simple-presence-07.txt
  • - draft-ietf-simple-winfo-format-02.txt
  • - draft-ietf-simple-winfo-package-02.txt
  • - draft-ietf-simple-cpim-mapping-01.txt
  • - draft-ietf-simple-presencelist-package-00.txt
  • No Request For Comments

    Current Meeting Report

    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 
    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 
    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 
    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 
     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 
     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 
    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 
    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 
    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 
     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 
    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 


    PUBLISH Framework
    3GPP Messaging Requirements
    3GPP Presence Requirements
    SIMPLE PIDF Extensions
    Event List Template: Open Issues
    SIMPLE Data Requirements
    SIMPLE List Manipulation Semantics
    Message Sessions