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

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional SIMPLE Web Page

Last Modified: 2005-10-03


Robert Sparks <rjsparks@nostrum.com>
Hisham Khartabil <hisham.khartabil@telio.no>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <shollenbeck@verisign.com>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Technical Advisor(s):

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: simple@ietf.org
To Subscribe: simple-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/simple/index.html

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
instant messaging and presence (IMP). The IETF has committed to
producing an interoperable standard for these services compliant to
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

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
presence format to describe typical IM states. Each of these
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
with the SIP processes for extensions. The group cannot modify
SIP behavior or define a new version of SIP for IM and presence. If
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
and avoid reinvention of the wheel. The working group will cooperate
with the SIP working group, soliciting reviews to ensure its
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:

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
Done  Submission of requirements for event publishing to the IESG for publication as Proposed Standard
Done  Submission of proposed mechanism for event publishing to the SIP working group
May 2004  Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard
May 2004  Submission of base XCAP draft to IESG for publication as Proposed Standard
May 2004  Submission of XCAP event package to IESG for for publication as Proposed Standard
May 2004  Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard
May 2004  Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard
Jun 2004  Submission of XCAP usage for manipulation of presence document content
Jun 2004  Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard
Jul 2004  Submission of Filtering mechanisms to IESG for publication as a Proposed Standard
Jul 2004  Submission of CPIM mapping draft to IESG for publication as Informational
Jul 2004  Submission of instant messaging session draft to IESG for publication as a Proposed Standard
Jul 2004  Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards
Aug 2004  Submission of advanced messaging requirements draft to IESG for publication as Informational
Sep 2004  Submission of proposed mechnisms meeting the advanced messaging requirements to the IESG or appropriate working group
Sep 2004  Submission of Presence/IM System Architecture draft to IESG for publication as Informational


  • draft-ietf-simple-event-list-07.txt
  • draft-ietf-simple-message-sessions-12.txt
  • draft-ietf-simple-xcap-08.txt
  • draft-ietf-simple-xcap-list-usage-05.txt
  • draft-ietf-simple-rpid-09.txt
  • draft-ietf-simple-partial-notify-06.txt
  • draft-ietf-simple-partial-pidf-format-05.txt
  • draft-ietf-simple-event-filter-funct-05.txt
  • draft-ietf-simple-filter-format-05.txt
  • draft-ietf-simple-prescaps-ext-05.txt
  • draft-ietf-simple-cipid-06.txt
  • draft-ietf-simple-future-04.txt
  • draft-ietf-simple-presence-rules-04.txt
  • draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt
  • draft-ietf-simple-msrp-relays-05.txt
  • draft-ietf-simple-presence-data-model-06.txt
  • draft-ietf-simple-partial-publish-03.txt
  • draft-ietf-simple-xcap-diff-02.txt
  • draft-ietf-simple-pres-policy-caps-00.txt
  • draft-ietf-simple-common-policy-caps-00.txt

    Request For Comments:

    RFC3856 Standard A Presence Event Package for the Session Initiation Protocol (SIP)
    RFC3857 Standard A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)
    RFC3858 Standard An Extensible Markup Language (XML) Based Format for Watcher Information
    RFC3994 Standard Indication of Message Composition for Instant Messaging

    Current Meeting Report

    Notes reported by Dean Willis
    Chaired by Robert Sparks, Hisham Khartabil
    0900-1130 Friday November 11, 2005
    Vancouver, BC, Canada
    - MSRP will change by altering the fixed size of non-SEND requests and adding
      text describing end-to-end communication with mutual TLS and self-signed
      certs. Both the base and relay drafts are expected to be submitted for
      publication within the next few weeks
    - The working group agreed to adopt draft-urpalainen-simple-xml-patch-ops as a
      working group item addressing the needs of the partial-* drafts and for
    - XCAP will be pulled from the RFC editor queue and bugs around extensibility
      and namespace selection requiring minor changes will be fixed. There are a
      couple of more major changes, in particular reopening whether XCAP allows
      conditional insertions, under discussion. We will coordinate with OMA as we
      discuss those proposals.
    - Presence Authorization is essentially done, depending only on closing the
      open issues in the common-policy work and aligning with the final version of
      that draft.
    - The partial-* drafts are ready for last call.
    - IMDN is progressing, issues are being closed
    - New drafts:
        - The PIDF Connections proposal was well received, and several suggestions
          for improvement were made during the session.  Additional list discussion
          is encouraged.
        - Feedback on the Resource Information List proposal was that significant
          thought to security will need to go into any revision of this draft
        - The XCAP profile proposal stirred active, inconclusive, debate over
          several subtopics. Further discussion was sent to the list.
    Full Notes:
    Topic: Revised agenda presented by chairs.
    Slides presented.
    Issue: Status reviewed by chairs. 
    Issue: MSRP update
    Will increased fixed size. Will add section describing endpoints with mutual
    TLS and self-signed certs. Will  then send to IESG. There may be a discussion
    on the sizes. This should happen in next few weeks.
    Topic: IMDN
    Led by Eric Burger
    Slides Presented
    6 open issues raised and discussed on list
    Issue 1: Security of notification
    Several proposals offered relating to encryption of message body 
    (listed in slides). 
    Room polled for preference. Ted stated preference for "encrypt body if message
    was encrypted". Recommendation accepted unanimously by room but will be
    reviewed on list.
    Issue 2: Sender Keeping State
    Suggested that we not change from what the draft says. Noted that point
    "minimum info from IMDN" is critical, and we can do things like validate that a
    specific message arrived with current text. Noted also that clienst are likely
    to throw away IMDNs for which they don't have stored state. Suggested that we
    adjust wording in draft to not talk about state, but about the minimization of
    information in IMDN itself.
    Issue 3: No Disposition time in IMDN
    Question (Cullen): Is there another date around that would have to be
    reconciled? Suggested that the draft should say "Don't trust any dates but what
    you get from the transport protocol. Question: How does this affect record
    requirements for financial industries? Answer: draft says "don't do this with
    IMDN". Other workarounds exist.
    Issue 4: Recipient of IMDN can appear to be different from sender.
    draft suggests authenticated transport for IM transport. Question raised: There
    are use cases for sending IMDN via different transport than message. For
    example, MSRP answering machine that stores a message for later playback might
    use email for IMDN or other non-session thing. Ted suggest that we "minimize
    complexity". Poll: Anybody here need this feature? None in room. Resolved to
    double-check this on list.
    Issue 5: Deleted State
    Proposed that we drop deleted state altogether from design. Poll: Does anybody
    want to keep "deleted" as a reporting state? Cullen reports that he thinks
    somebody was using this, possibly reported in Paris and in the financial
    sector. Resolved to discuss on list.
    Issue 6: Report Consolidation
    Proposed to say no but retain placeholder for future extension. Suggested it is
    important that relays NOT explode IMDNs.  Relaying through multiple B2BUAs was
    discussed. Chair declares consensus on behalf of proposal.
    Issue: Does anyone care? Miguel reports that OMA MWG is looking at this. Adam
    reports that he has customer requirements for this and will be implementing it
    and would like it to be standardized. Keith clarifies 3GPP position as being in
    a feasibility study with no official dependencies.  Ben also reports a need for
    standardization. Poll: Who in the room will work on this: Chair reports
    "enough". Poll: Adopt as WG item? Unanimous response in favor.
    Topic: XML Patch Ops BoF
    chairs report on discussion in this BoF. The BoF was not interested in building
    a general xml diff tool. Compromise agreed to move forward with our drafts and
    roughly what Jari has in his diff tools now.
    Topic: XCAP
    Led by Jonathan Rosenberg
    Slides Presented
    draft-ietf-simple-xcap-07 was in RFC Ed queue. Proposed that we yank from
    queue, revise to fix XCAP namespace issue and several reported bugs and
    extensibility problem and namespace problem.
    The -08 version includes text to fix these things. Slides review the changes. 
    Changes not noted here received no counter-discussion in meeting.
    Issue: Whitespace vs comment nodes.  
    Proposal is questionable in use of mixed text and will be discussed on list.
    Issue: Document Selector. 
    Noted (Derek) that OMA does similar things but has their own names. Proposed
    that we coordinate with OMA on these conventions. Author, chairs, and liaison
    tasked to work this out.
    Issue: Namespace proposal.   
    Get and Namespaces. Proposed that we reject canonical XML approach. Use
    proposal 2 for blind insertions.  Discussed possibility of requiring server to
    munge namespaces appropriately in some depth (it basically doesn't work).
    Several people spoke in favor of proposal from slides.
    Issue; The Insertion Problem. 
    Proposed to make non-extant resources extant but empty if the parent exists.
    Question: This would appear to break conditional tests "does this element
    exist?". Discussion revealed that that the logic for the test changes (test on
    element not resource but can still be implemented. Proposed that it is worth
    writing a draft about and discussing. Noted by Ted Hardie that a change of this
    magnitude would require a full recycle through the IETF publication review
    process. Further discussion on requirements and mechanism and implications
    followed. Joel noted that this breaks the ability to "Insert this buddy if I
    haven't used the name already", which might be important. Question: Is it
    possible to fix XCAP for OMA now, and leave the "insertion problem" for later
    as an extension? We can ask OMA if this would work for them, but it remains
    unclear as to whether this WG will accept the approach. Jonathan will write
    this up and communicate it with WG and OMA.
    Topic: Presence Authorization
    led by Jonathan Rosenberg
    slides presented
    Relates to conclusions in geopriv on common policy.
    Henning suggests "3897 and be done with it".
    Issue: Anonymity. Can't currently differentiate "unauthenticated" and
    Poll: Do we agree to maintain text that does not differentiate anonymous for
    now? Response appears to be unanimous. The plan forward is that Hannes will
    revise common-policy soon, and then Jonathan will revise this draft to match.
    Topic: XCAP Diff
    led by Jonathan Rosenberg
    Slides presented
    draft-simple-change-log will be essentially abandoned unless we bog down with
    current mechanism completely. 
    Issue: Extending xcap-diff. 
    Two approaches described. Discussion followed. There seems to be some kind of
    issue with Approach 1. The conclusion is dependent on the related change
    proposal discussed in the slide and cannot be determined at this time. Noted
    that HTTP responses require a Content-Length, which breaks one of the ideas
    Topic: Partial PIDF
    led by Jari Urpalaienen
    Slides Presented
    Changes from -03 reviewed
    Poll: Does anyone believe that these drafts are not ready for WGLC? None
    opposed. Chairs plan to announce WGLC within next few weeks.
    Topic: Simplified XCAP profile
    led by Rohan Mahy
    Slides presented
    Lighweight profile discussed.
    Henning is averse to the protocol fragmentation he sees resulting from this
    approach, and doens't want to have to build on a generic XML database.
    Jonathan thinks it is useful to talk about client simplifications, but that
    simplifying the server will create interop problems and effectively multiple
    different protocols for different usages. 
    Jari believes that the additional server code needed to implement the full xcap
    to be minimal.
    Robert suggests that this doesn't really break the XCAP model. Each profile is
    simply a declaration of policy.
    Keith asks whether this approach actually increases the client complexity by
    requiring it to negotiate and understand profiles. 
    Jonathan noted that this would appear to require updates of the list usages and
    other documents in order to reference the profile document.
    Derek worries that this might increase client complexity via a requirement to
    annotate the tree for the profile.
    Dan suggests that this approach is a natural optimization towards launching and
    deploying XCAP services sooner rather than later.
    Keith suggested that we're not talking about a profile, but a change to
    normative behavior and therefore not a profile.
    Joel reports that previous attempts to build restricted implementations have
    often failed due to a mismatch between what the clients want to do and what the
    profile does.
    Ted asks if this is something we could accomplish by declaring these as
    different "XCAP applications" (AUIDs) .
    Henning suggests a compromise possibility. Perhaps these "profiles" constitute
    a recommended set of operations that clients should stick to that would be
    "efficient" on the server, and that if clients step back to the more complex
    operations, it might be reasonable to do the "full functions" via a slower,
    brute force manner.
    Adam notes that the server functionality is not lost in absolute terms with
    these profiles, but might require the client to send a larger data set in order
    to meet the function.
    Poll: is it worth exploring XCAP ideas relating to depth restriction on
    servers? The result was declared inconclusive by the chairs.
    Topic: Resource Information List
    led by Rocky Wang
    Slides presented
    General idea is on providing a mechanism for informing watchers about partial
    subscription satisfaction.
    Chair encourages participants to read this draft.
    Noted that there is a privacy consideration raised by revealing the information
    that a watcher is not allowed to see, and that any future revision will need to
    explore this issue
    Topic: PIDF Connections
    Led by Jussi Ala-Kurikka
    Slides presented
    Attempts to describe relative cost to correspondent of exercising a particular
    device tuple as described in PIDF.
    Jonathan suggests that the draft provides useful assistance in tuple selection.
    He cautions that trying to express the absolute cost is likely to cause
    problems.  he would like to add this as a WG item, but would prefer to defer it
    until more of the current work is finished.
    Henry notes that there seems to be some overlap between this work and
    lower-layer efforts at layer 2, and that the draft is timely.
    Robert (not as chair) thinks that the draft is interesting and that the authors
    should resist the temptation to over-extend the information expressed. However,
    he would prefer not to offer the draft for adoption by the WG at this time.
    Henning notes that the access-network bandwidth is often not the limiting
    factor. he thinks the useful information can be presented as one bit for "costs
    this user" and a few more for order-of-magnitude ranges on bandwidth.


    Chair slides - administrivia
    IMDN (pdf)
    IMDN (ppt)
    Presence RIL
    -partial- drafts
    Presence rules
    xcap profile