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

Last Modified: 2003-06-16

Robert Sparks <rsparks@dynamicsoft.com>
Jon Peterson <jon.peterson@neustar.biz>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.com>
Mailing Lists:
General Discussion: simple@ietf.org
To Subscribe: simple-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/working-groups/simple/current/maillist.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 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

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.
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
Jun 03  Submission of requirements for event publishing to the IESG for publication as Proposed Standard
Jun 03  Submission of proposed mechanism for event publishing to the SIP working group
Jun 03  Submission of presencelist auth/modify requirements draft to IESG for publication as Informational
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
  • - draft-ietf-simple-presence-10.txt
  • - draft-ietf-simple-winfo-format-04.txt
  • - draft-ietf-simple-winfo-package-05.txt
  • - draft-ietf-simple-data-req-03.txt
  • - draft-ietf-simple-publish-reqs-00.txt
  • - draft-ietf-simple-event-list-04.txt
  • - draft-ietf-simple-publish-01.txt
  • - draft-ietf-simple-presinfo-deliv-reg-00.txt
  • - draft-ietf-simple-winfo-filter-reqs-00.txt
  • - draft-ietf-simple-message-sessions-01.txt
  • - draft-ietf-simple-pres-filter-reqs-02.txt
  • - draft-ietf-simple-xcap-auth-usage-00.txt
  • - draft-ietf-simple-xcap-00.txt
  • - draft-ietf-simple-xcap-package-00.txt
  • - draft-ietf-simple-xcap-list-usage-00.txt
  • - draft-ietf-simple-rpid-00.txt
  • No Request For Comments

    Current Meeting Report

    Monday July 14, 2003, 1430-1630 Hall G
    Chairs: Jon Peterson, Robert Sparks
    Minutes taken by Dean Willis.
    Meeting called to order by Robert Sparks 
    Agenda review
    No changes.
    Simple Arch Draft, Avshalom Houri
    Slides presented.
    Rationale, mission, and status of draft reviewed. 
    Need to prune scope of draft, as if completed with current outline it 
    would be longer than RFC3261. WG is asked to review and comment on the 
    list. Volunteers for sections are requested to step forward.
    Comment: Aki Niemi suggests breaking it up into three different 
    documents: Example call flows, document summary, and descriptions of 
    Message Sessions, Ben Campbell
    Slides presented.
    Reviewed discussion from interim meeting in Ottawa.  Draft is 
    currently in WGLC.
    Discussion of accept-wrapped-types attribute to clarify text of slide. 
    Draft is correct, but example on slide is misleading.
    We need a better estimation of the session inactivity timer values.
    Question: How do you take a relay out of service for 
    administrative reasons. We once had a way to inform users that this could 
    happen. We did this before by not allowing a lease renewal. Since this has 
    been replaced by auto-renewing timers, this doesn't work anymore. This 
    needs to be discussed on list to see if we still need the 
    administrative function.
    Adopting a well-known service port. Note that negotiation will still 
    provide a port, but it should generally be the wks number. The text 
    includes IANA boilerplate for a port assignment. Is this all we need to do 
    for a port number, or do we need to use the online form for port number 
    assignment? AD discussed process -- since we can test without the IANA 
    action, we can proceed with IANA considerations section in document.
    Open Issue, Clean Shutdown: Do we need to make sure there are no 
    outstanding SENDS before ending a session? Consensus that the 
    possibility of pending messages needs to be discussed in the draft. 
    Open Issue, 426 Response Code Extensibility: Does this need to be 
    extensible to other protection types? Consensus, no.
    Open Issue, Session Inactivity Timer: Does this need to be something 
    different than 1 minute?
    Open Issue, StartTLS: Discussion indicates that a 3-byte lookahead is 
    enough to detect a start-TLS. Should we add one? Consensus: yes
    Poll: Are we happy enough with the doc that we can finish the nits and send 
    it to IESG? Answer: Yes.
    Data Manipulation, Jonathan Rosenberg
    Slides presented.
    XCAP Issue #1, actual filesystem hierarchy for buddy lists: 
    Discussion indicates that what we're really talking about is atomicity of 
    resources, not filesystems. 
    Batching operations: Solution here is not to do batching now.
    Proposal on HTTP usage: accepted by consensus.
    Open issue: HTTP limitations. Discussion that we can use separate 
    sub-URIs instead of XPATH. 
    Data Manipulation Requirements: Proposal accepted.
    Issue, Union vs Most Specific: Proposal to union offered, discussion 
    Many open issues not discussed.
    Publication, Aki Niemi
    Slides presented. 
    Changes since last version reviewed
    Open issue, Atomicity of publication: 3 options presented. This is 
    essentially the partial publication problem as Jon Peterson 
    undertands it. Is this in scope at this time?  Comment: this applies to any 
    event package with segmented information, such as watcher-info. Much 
    discussion with no conclusions.
    Event Filtering Requirements, Hisham Khartabil
    Open issue: watcher "learning new items of the presence 
    information"? Do we need this capability as a requirement? Proposed that we 
    reject this requirement at this time. Poll for volunteers to formally 
    review: Ben Campbell, Avashalom Houri, Jonathan Rosenberg
    SIMPLE Filter Format, Hisham Khartabil
    Issue, XPath Usage: used to declare the elements that should be 
    included in the NOTIFY body. Comment that XPath is a very heavy tool. 
    Another issue is that the expressivity of a raw element name is 
    insufficient for dealing with complexities of derived and 
    transformed data. 
    Issue, Current draft applies filters to URIs: Is something more like 
    authorization list (allows domains) more appropriate?
    Issue, Full or partial state?: Not discussed.
    Issue, Server in a foreign network: Can we enforce filtering in 
    intermediate nodes? Deferred to list.
    Issue: Subscribe refresh with selected filter indications. Discussed, no 
    conclusion, deferred to list.
    Partial Notification, Robert Sparks
    (Mikko did not get to discuss this draft during the meeting due to time 
    Poll: accept this as a working group item if it can be added to 
    charter? Hum, as evaluated by chair, indicated consensus to accept.
    RPIDS, Henning Schulzrinne
    Slides presented.
    Material reviewed in presentation. 
    Issue, Document structure options: Proposed that <from> time element be 
    moved into predictive presence category. Discussion will follow.
    Open Issue, DND: Used priority indication in previous revs. 
    Discussed, no apparent conclusion.
    Open issue, XML declarations of attribute values. Proposal accepted.
    Presence Capabilities, Lonnfors
    Discussion as to whether we are ready to see this as a WG item. Chairs 
    decided that another rev is required first.


    SIMPLE Architecture draft
    Message Sessions
    Data Manipulation
    Event Filtering