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

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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-06-27


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-11.txt
  • draft-ietf-simple-xcap-07.txt
  • draft-ietf-simple-xcap-list-usage-05.txt
  • draft-ietf-simple-rpid-08.txt
  • draft-ietf-simple-partial-notify-05.txt
  • draft-ietf-simple-partial-pidf-format-04.txt
  • draft-ietf-simple-event-filter-funct-05.txt
  • draft-ietf-simple-filter-format-05.txt
  • draft-ietf-simple-prescaps-ext-04.txt
  • draft-ietf-simple-cipid-06.txt
  • draft-ietf-simple-future-04.txt
  • draft-ietf-simple-presence-rules-03.txt
  • draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt
  • draft-ietf-simple-msrp-relays-05.txt
  • draft-ietf-simple-presence-data-model-03.txt
  • draft-ietf-simple-partial-publish-03.txt
  • draft-ietf-simple-xcap-diff-01.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

    SIMPLE WG Minutes IETF 63 SIMPLE Minutes
    IETF 63
    Thursday, August 4, 2005
    1400-1630 Afternoon Session I

    Executive Summary

    In IETF 63, the SIMPLE working group met once for a 2.5 hour session. The chairs presented a short-term roadmap outlining the WGLC and IESG submission plans for the next 2-3 months. Those included RPID and related drafts, MSRP and MSRP relay drafts, presence rules drafts, and partial notification and related drafts.

    Presence Data and Presence processing model drafts seem to be at their final stages with very minor issues. WGLC will be called soon. Presence Authorisation is at the same stage and the processing model drafts. There is consensus from the group.

    These is still a cotroversy over XML diff and its deviation from what the WG asked for. The issue also exteds to XCAP diff where it has its own XML diff solution different from what is in the XML diff draft. Consolidation work between XCAP diff and XML diff drafts is needed or narrowing of scope of the XML diff work to be specific to partial notification is needed. There is no consensus from the group one way or the other. More work is needed by the authors of the 2 drafts.

    Composition policy ideas where presented in the meeting. The group feels that this work is too early.

    Message delivery reporting ideas were also presented. The group indicated interest in such work and the authors of the 2 drafts that were presented agreed to merge their efforts.

    Jonathan Rosenberg noted a mistake in the notes taken for the data model.

    Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO encapsulation out of data model spec. Argued that this makes for a lot of documents to read in order to get an implementation. General consensus on proposal.

    Jonahtan recalls that Henning argued against this, and the conclusion was to just put words in. No one objected to such comment.

    Detailed Minutes

    Topic: Chair Update
    XCAP is RFC editor queue
    Short-term roadmap presented

    Topic: Presence Data Model
    Jonathan Rosenberg
    Slides presented

    Note: the schema needs to be updated to match what;s in the SIP Foundry repository.

    Issue 1:
    Verified/Unverified. Solution accepted as proposed. The impact of GI/GO should be noted in the text, at a SHOULD rather than MUST level.

    Suggested text add: When you create an originally new document, it must be valid. Rohan promised to send appropriate text.

    Issue 2:
    Aliasing. Solution accepted as proposed.

    Issue 2; Schema.
     fromUntil vs sinceUntilProposal to adjust RPID schema accepted.

    Issue 3: Schema.  deviceID:
    Proposed to define only as a global element. Proposal accepted. Note that this will change the schema in RPID.

    Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO encapsulation out of data model spec. Argued that this makes for a lot of documents to read in order to get an implementation. General consensus on proposal.

    Topic: Presence Processing Model
    Slides presented

    Changes since last rev reviewed

    Proposed that further work here be deferred until more critical documents are done and more experience gained. There was general consensus on this approach.

    Topic: Presence Authorization
    Jonathan Rosenberg
    Slides presented

    Changes since last rev reviewed.

    Issue; Sphere determination.

    To Do: Make the hook for sphere composition more explicit.

    Topic: XCAP Diff
    Jonathan Rosenberg
    Slides presented

    Changes since last rev presented

    No known open issues except disconnection with partial publication (different patch format).  many documents blocked on this.

    Proposed that we have review and WGLC.

    Noted that the impact of different patch implementation might not have a dramatic impact.

    Suggested that we use a multipart MIME approach to  Basically, we would put the metadata in an initial text data. This would prevent the CDATA escaping need to handle embedded markup in the current format.

    Proposed: Punt and say that the xml-diff format indicates only that the document has changed (notification of change by reference rather than by value).

    AD comment: Not worthing doing this just to advise people a document has changed. But the CDATA problem probably bears closer examination. And this task DOES need completion, even if only a piece is split off to meet the near-term requirements.

    Next steps; Talk to the XML folks about solving the problem, and if necessary, fall back to change-by-reference.

    Topic: Partial PIDF format 04
    Slides Presented

    Noted by chair that scope of this draft seems to have expanded since last rev, possibly in disagreement with consensus of last meeting.  This may require some examination. The authors are cautioned to inform the WG if they see a future need for this sort of scope change.

    Noted that this approach has been implemented and seems to work.

    Comment: One implementor believes that this spec will be much more difficult to implement than core XCAP was.

    Proposed: People should look a drafts using this function and see if this draft has enabled a better solution, then decide.

    Noted that the developer of partial notify and related material has found this approach very useful.

    Poll: How many people are actively following: Few

    How many are actively implementing? Even less. . .

    Open question: Can we produce a general XML patch mechanism? AD comment: Very concerned that this may not meet the XCAP design goals. If it does, then it's OK if it's also generally usable. But we have no need to prove that it is a general mechanism in order to proceed.

    Chair comment: We can present this as specific to partial notification, even if the algorithms are more useful.

    Proposed that we have a con-call with the XML directorate to review this. The ADs will assist with scheduling and selecting the right people.

    Proposed by Chair: This seems to be a reasonable way to move forward if it works, and after review with the XML people the WG will be informed.

    Topic: Common Policy
    Henning Schulzrinne
    Slides presented

    Current solution reviewed.

    Issue: Authenticated vs Asserted

    The current draft has some discussion without use cases.  Suggested that this text be deleted and a richer discussion elsewhere be referenced. Debate followed with no clear conclusion.

    Issue: Processing Logic

    Question: Allow OR conditions within various  sections? Currently defined only for <identity>.

    Question; Allow >=1 (groups) .

    Discussion followed.

    Question: Can this accept everybody BUT a specific individual? Yes, it could.

    Seems to be general consensus to accept proposal.

    Issue: Tel URIs;

    Proposal to only allow domain identifiers in <many /> clauses., and non-domain identifiers in <one/> clauses.

    Discussion followed.

    Noted that tel: is not the only class of non-domain identifiers.

    Noted that this proposal prevents exclusions on ranges of numbers

    Suggested that exclude clauses be restricted to members of the surrounding group element.

    Suggested that each rule element apply to a single URI scheme type, like sip: or xmpp:.

    Chair comment: How long do we think it would take to navigate our way through this? Would it be reasonable to plan for EGLCZ on presence rules at the end of September? The sense of the room is favorable to this position.

    Proposed that we need to do a requirements document. This proposal was met with general disdain.

    These general discussion questions need to be raised on the mailing list.

    Topic: Presence Composition
    Henning Schulzrinne
    Slides presented

    Previous discussions summarized.

    Comment: It might be nice to be able to apply credibility factors to the composition. This is complicated by the lack of a source attribution in each element.

    Issue: Source Labeling

    Issue; Simple Composition Policy Language

    Comment: Composition of "lunch" and "meeting" is difficult -- is this a lunch meeting, lunch, or a meeting?

    Comment: Presence extrapolation is an interesting problem.

    Comment: This problem is similar to the configuration merging problem.

    Comment Yes, but presence composition errors aren't going to result in device crashes or interop failures.

    Comment: This is a very low priority topic.

    Comment: A recent exercise in client-side composition revealed that there are 4 or 5 categories of data, with one type of merging algorithm appropriate for that data type.

    Comment: Conflicting information can be presented to and analyzed by humans.

    Comment; There DOES need to be a way for the user to influence the composition policy in order to get useful information in/out of a system.

    Comment: One the things that was in the presence processing model was guidance about how a user sets things.

    Topic: Messaging and Delivery Notfication
    Hisham Khartabil
    Slides presented

    Topic: IMDN
    Eric Burger
    Slides presented

    Discussion of two preceding:

    Comment: Recent experience with customers indicates a need to solve this problem. Both drafts look like a good start but would be better combined.

    Comment: Delivery notification would be useful for calendar notifications.

    Discussion of XML vs not-XML inconclusive.

    Topic: Translation of Schema to WebDAV
    Rohan Mahy
    Slides presented

    Comment: JDR sees no value in this approach.

    Comment: The functionality of locking mechanism could be very useful.


    Chair Update
    A Data Model for Presence
    A Processing Model Presence
    Presence Authorization Rules
    An XML Document Format for Indicating Changes in XCAP Resources
    XML Patch Operations
    PIDF Extension for Partial Presence
    SIP extension for Partial Notification of Presence Information
    Publication of Partial Presence Information
    A Document Format for Expressing Privacy Preferences (Common Policy)
    Composing Presence Information
    Instant Message Delivery and Read Reports
    IMDN for Common Presence and Instant Messaging (CPIM) Messages