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

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. 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-03-02


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

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

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 04  Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard
May 04  Submission of base XCAP draft to IESG for publication as Proposed Standard
May 04  Submission of XCAP event package to IESG for for publication as Proposed Standard
May 04  Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard
May 04  Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard
Jun 04  Submission of XCAP usage for manipulation of presence document content
Jun 04  Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard
Jul 04  Submission of Filtering mechanisms to IESG for publication as a Proposed Standard
Jul 04  Submission of CPIM mapping draft to IESG for publication as Informational
Jul 04  Submission of instant messaging session draft to IESG for publication as a Proposed Standard
Jul 04  Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards
Aug 04  Submission of advanced messaging requirements draft to IESG for publication as Informational
Sep 04  Submission of proposed mechnisms meeting the advanced messaging requirements to the IESG or appropriate working group
Sep 04  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-10.txt
  • draft-ietf-simple-xcap-06.txt
  • draft-ietf-simple-xcap-package-03.txt
  • draft-ietf-simple-xcap-list-usage-05.txt
  • draft-ietf-simple-rpid-05.txt
  • draft-ietf-simple-partial-notify-04.txt
  • draft-ietf-simple-partial-pidf-format-03.txt
  • draft-ietf-simple-event-filter-funct-04.txt
  • draft-ietf-simple-filter-format-04.txt
  • draft-ietf-simple-prescaps-ext-03.txt
  • draft-ietf-simple-presence-rules-02.txt
  • draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt
  • draft-ietf-simple-msrp-relays-03.txt
  • draft-ietf-simple-presence-data-model-02.txt
  • draft-ietf-simple-partial-publish-02.txt
  • draft-ietf-simple-xcap-diff-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

    SIMPLE IETF 62 Meeting Minutes
    Minutes - IETF 62
    (thanks to Dean Willis and Chris Boulton)
    Session One:
    Recorded by Dean Willis
    3/7/05 1300-1500
    Henning Schulzrinne
    Slides presented
    Issue: Debate on "unknown" element for lists (like activities) -- "empty" vs
    "null" Do we need to be able to distinguish between an empty element and a
    non-existent element?
    Noted that we use the same syntax for both publication and notification. Should
    we include discussion of the composition aspects of the schema?
    Argued: We don't want to use the presence documents themselves as a statement
    of policy on composition functions. If it tells the presence service how to do
    something, it doesn't belong in the presence document.
    Comment: Is this just a terminology issue: If we replace "unknown" with
    "other", would that solve the problem?
    Comment: it seems to be useful to have the ability to differentiate an explicit
    assertion of neutral state vs a state about which no assertions are being made,
    independent of the composition policy.
    Poll: Should we include unknown elements at each enumeration? Rough consensus
    in favor of inclusion.
    Issue: Do we include source/type identification? This seems to be problematic
    from an authorization perspective, and impossible to completely enumerate.
    Proposed that we exclude source/type identification from the current effort.
    Proposal accepted.
    plans are to release -06 immediately after IETF 62.
    Presence Data Model
    Jonathan Rosenberg
    Slides presented.
    Changes since last rev reviewed.
    Open Issues:
    Issue #1 Do we need an enumeration of services? A service registry has been
    proposed. Author proposes not, that reach information suffices.
    Comment: The reach information is useful and adequate to solve the problem.
    Noted: Reach information is a child of tuple, not status. This needs to be
    clearly stated in the document.
    Comment: The examples need to be consistent with recommendations in callee-caps.
    Note: Add discussion about the interpretation of non-existing data to data
    model. Prescaps need to follow the callee-caps model.
    Issue #2: Available IM, Not Audio
    Do we need to address this in the data model? Author believes the current text
    leaves the decision open.
    Consensus to add to the data model words indicating that capabilities can
    change, and to include example possibly based on Aki's example.
    Debate point: Just because I'm busy for IM, it doesn't mean I can't receive IM.
    Can we distinguish between capabilities and availabilities? Does "future
    status" work? It might if we eliminated the target time for future status -- 
    "I expect to be available for calls sometime".
    Issue #3: Three Dimensions
    Do we need to model these in the data model? Proposed "No". Consensus reported
    on this proposal.
    Issue #3 Device ID URN
    Proposed to note that these things can change, that they can be derived from
    different things, and punt the detail implementation for each of these to new
    Issue that we need to be able to differentiate an correlate information from
    separate devices vs. correlate information for one device with multiple IDs.
    So, what's the problem with UUIDs? Since they are randomly generated, sometimes
    from a MAC, can they be correlated with a MAC address? Are they "invertable?
    Arguable that they are not -- one cannot assume that just because a UUID has a
    MAC address in it that the UUID is from the device that has that MAC address.
    Action Item: We need to check on relationship between UUID and ESN, MEID, IMEI,
    and IMSI from mobile worlds.
    Noted that this mechanism works, it just works better if we have more information.
    Proposed: To note that the draft use a UUID URN as the baseline, and allow
    others as available. Rough consensus observed.
    Issue: Multiple device IDs.
    Noted that we need to clean up the difference between the device-ID element and
    the ID element of the device.  Rough consensus reported on a single device ID
    per device.
    Presence Authorization Rules
    Jonathan Rosenberg
    Slides presented
    Changes since last draft reviewed.
    Issue #1: Blacklists and matching.
    Proposal offered by author. Response controversial. Noted that real world cases
    seem to require cross-domain listing now.
    Much debate ensued. Author will add many caveats about identity minting.
    Henning and others will discuss additive properties.
    Poll: Inconclusive.
    Issue #2: Glob Matching
    Proposed and accepted; do not add this feature.
    Issue #3: Filter-based sub-handling
    Proposed: leave as is; Accepted.
    Issue #4 Tel URI
    Action item: Make sure it works with tel URI as an identity.
    SIMPLE Session II - 8th March 2005
    Recorded by Dean Willis
    3/8/05 0900-1130
    Topic: MSRP
    Ben Campbell
    Slides presented.
    Changes since last version reviewed.
    Comment: Additional registration may be needed for SDP content type when TLS is
    to be used, perhaps msrp/tcp/tls.
    Issue:  Overlapping data 
    General consensus noted on suggested approach to
    clarifying wording as non-normative, with example of "if already rendered" to
    be used.
    Proposed that document is ready for working group last call
    Topic: MSRP Relay
    Cullen Jennings
    Slides presented.
    Changes since last version reviewed.
    Discussed whether basic authentication may leak data when the TLS connection is
    terminated through a hotel proxy, so this may need discussion in the security
    Question: Should stateless relay implementation (in appendix A) stay? Proposed
    that if we want to keep the text, we might want to move it to a separate
    informational draft.  Also proposed that we simply delete the appendix.
    Consensus to delete appendix A reported.
    Question: What else needs to be resolved before the document will be ready for
    last call? Need to clarify some base draft text on handling for new methods.
    Topic: MSRP Conferences
    Miguel-Angel Garcia Martín
    Slides presented.
    Comment: It's possible that we might discover from XCON that extensions are
    needed to lots of things to make them conference right. Once we've started
    putting distribution lists into bodies, we may not need the distsend method and
    distribution header. Suggested that it would be better to have a general
    mechanism instead of extending each protocol. Extended discussion followed.
    Comment: We need a way to manage the overlap between this work in the three
    working groups that are discussing it -- xcon, simple, and sipping.
    Comment: We need more clarity on what is happening in xcon, such as subsets of
    conferences, before we can really do proper conferencing extensions to MSRP.
    Comment: requirements should be taken into xcon and handled there, rather than
    being piecemealed in each protocol working group. The requirements in this doc
    seem reasonable and should be taken to xcon.
    Comment: There seem to be huge disconnects in the meaning of "nickname" to
    different people in this discussion.
    Chair comment: nicknames are NOT a SIMPLE problem. Where should they live?
    Question on requirements: Since ordered delivery is a requirement, is there a
    requirement that if some recipient does not receive a message, should all other
    recipients stop receiving messages? Further discussion is needed.
    Proposed that we assemble a team to determine how to do nicknames across the
    whole SIPpish community.
    Comment: There seems to be a real requirement to communicate message
    sequencing, if not to assure in-order delivery. We should carefully reword this
    to be solvable.
    Comment: Any attempt to define new identifiers raises many questions, including
    scope, membership of namespace, identity assertion, etc.
    Conclusion: we will discuss further and see if some approach comes out.
    Topic XML Patch Operations
    Jari Urpalienen
    Slides presented.
    Changes since last version reviewed.
    Comments: Very concerned about a scope that appears to be defined as an
    alternative to xcap. Extended discussion followed.
    Poll: How many people read and understood this draft? A surprisingly large number.
    Comment: Document DOES seem to solve the problems that it targeted.
    Comment:  We seem to be trying to trying to reinvent document transformation.
    Debate followed, with a consensus resulting that "patching" is different from
    Comment: It seems like we have a bunch of working groups and outside orgs
    coming up with diff formats for xml. This suggests that we should, a most, do
    something very simple here (and Rohan has already suggested that xcap-diff is
    already too complicated). Or we could go work on the general problem.
    Comment: We don't need yet another way to modify documents. Also trying to
    implement this on top of a system that already uses xcap requires complex
    Comment: You probably want to look at xupdate, which is W3C work to do the same
    Comment: XCAP is a good general purpose mechanism. If we were starting over and
    just wanting to do buddy list management, something simpler would probably
    Chair comment: When we asked Jari to do this, we were asking for a solution to
    the first bullet -- resolving the different diff mechanisms we were already
    using. We got something more general. Question: Do we as a group wish to do a
    targeted solution for XCAP, or do something more general?
    Comment: For someone who is just worried about XCAP, any generalized mechanism
    requires trying to transform a diff set into a series of xcap operations.
    Comment: There is a sourceforge project ongoing to do an xmldiff solutiuon that
    is nearing publication.
    Proposed: If we do anything, it should be xcap specific.
    Chair comment: A general solution would probably be outside of our charter.
    Something that is specific to SIMPLE would be in our scope.
    Comment: We need to consider pidf-diff as well as xcap-diff.
    Chair Conclusion: It does not seem that this specific proposal (document under
    discussion) represents the path the group wishes to pursue. We will
    have to debate on list what the correct path is.
    Comment: Though sympathetic to the comments raised, nobody has suggested that
    this solution doesn't work. It would be a shame to dither for six months, then
    come back to this solution.
    Poll: If you think we need an advanced patch solution (general): Small
    response. If you think a narrow scope solution would be better: larger
    response. Undecided: larger response. Conclusion: inconclusive, more discussion
    needed on list.
    Topic: Policy Capabilities
    Jonathan Rosenberg
    Slides presented
    Poll: Who read? (reasonably small number).
    Question: Is the lack of comments an indication of consensus, or apathy?
    Poll: Should we adopt these two documents as a working group effort and go
    Consensus reported to proceed with adoption.
    Topic: User Agent Capability Extension to PIDF
    Aki Niemi
    Slides presented.
    Comment: doing a merge of two documents with conflicting priority value ranges
    is difficult. for example, if one document has "<4" and another has ">7", how
    do we compose them? Discussion followed, and somebody needs to go look at
    callee-caps and see what it can express (integer, restricted to the values of
    the priority header field, RFC 3840).
    Topic: Presence Processing Model
    Jonathan Rosenberg
    Slides presented.
    Issue #1: composing unknown attributes. No arguments to proposal.
    Issue #2: overrides. Rohan suggests that he has issues, but that they could not
    be resolved with 15 minutes of discussion.
    conclusion: Author will take issues to list as individual topics.
    SIMPLE Session II - 8th March 2005
    Provided by Chris Boulton
    MSRP Core - Ben Campbell
    - Discuss SDP changes - Review + concerns by MMUSIC on usage
      - Compromise solution based on copying address + port to conventional locations
    - Now referencing SDP new.
    - Added new response codes.
    - Other general cleanup issues sorted out in version 10 (security, IANA,
    -From list - Incremental REPORT vs Whole message.  Do not add feature for
    client to set preference at this time.
    -From list - Overlapping chunks when failover - WG consensus  - its the
    receivers problem - clarify text.
    - Robert Sparks : START WGLC AT THE MIC.
    MSRP relay - Cullen
    - Explanation of new AUTH processing (shared secret)
    - Other major changes covered (SDP, response codes, URI consistent with base
    - Remove Stateless relay text to avoid future issues
    MSRP Conferences - Miguel Garcia
    - Overview of exactly what is in the draft + requirements + proposed extensions.
    - Ben Campbell - We need a general solution, not specific MSRP extension -
      should be XCON work.
    - Brian Rosen - take your requirements and input to XCON rather than creating
      protocol specific solution in SIMPLE.
    - Paul - Believes there is a disconnect on the meaning of nickname
    - Brian Rosen - nickname - need to get together to agree nickname XCON,
    - JR - be careful when specifying new identifiers.
    - Robert Sparks - way forward - mostly XCON with nicknames discussion needed in
    XML Path Operations - Jari Urpalainen
    - Start with a short overview
    - Changes since last version of the draft
    - OPEN Issues and Bugs review - Included proposed solutions (see slide deck)
    - JR - concerns about technology.  Why is this draft being positioned as a
      replacement for XCAP?
    - Robert Sparks - thinks this draft is anything but simple (as positioned)
    - Cullen - Bunch of WG need Diff format for XML + are working on it.  We seem
      to be in the middle ground that describes a general mechanism for single
      problem area.
    - Robert Sparks - FEEDBACK FROM ROOM - Do we want to produce specific XCAP
      solution OR go outside the WG for a general purpose solution.
    - Rohan/JR - if we are going to use XCAP we should produce an XCAP specific
    - Robert Sparks - WG specific - proposal is not exactly what we want.  Probably
      need to tack back for XCAP specific and then PIDF OR look at a general
    - Hisham - HUM - No Conclusion - take to the list.
    Policy Capabilities - Jonathan
    - Problem Statement - How does a client know which of the auth policies it
    - Overview - Quick overview
    - Open Issues + should this be adopted as a WG item?
    - Robert Sparks - Should we adopt this work?
    - HUM - suggests WG adoption.
    Prescaps Update - Aki
    - Changes discussed form last version.
    - Rohan - Priority makes composition difficult.
    - Open Issues - no major just a couple of minor.  Update schema according to
      schema workshop design decisions.
    Presence Processing Model
    - Overview of changes in latest version
    - Draft represents bottom half of previous data model
    - Issues covered


    Presence Data Model
    Presence Authorization Rules
    MSRP - Base & Relay
    Conferencing with MSRP
    XML Patch Operations based on XPath selectors
    Policy Capabilities
    User Agent Capability Extension to Presence Information Data Format (PIDF)
    Presence Processing Model