Current Meeting Report

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

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/30/2002

Robert Sparks <>
J. Peterson <>
Applications Area Director(s):
Ned Freed <>
P. Faltstrom <>
Applications Area Advisor:
P. Faltstrom <>
Mailing Lists:
General Discussion:
To Subscribe:
Archive: Archive:
Description of Working Group:
This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 2543) 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 compatible with the requirements detailed in RFC 2779 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 and in CPIM and in BCP 41 (so that the transport implications of the extension with respect to network congestion are considered in the design). The extension will document the mappings from its operations to CPIM.

2. One or more proposed standard SIP extensions documenting a subscription and notification service within SIP, used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM. The extension will document the mappings from its operations to CPIM.

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 new security capabilities are needed from SIP, 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 method across the other applications being defined for its use.

Goals and Milestones:
MAR 01  Submission of Extensions for Instant Messaging to IESG
MAY 01  Submission of Extensions for Presence to IESG
  • - 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, IETF 54Minutes, SIMPLE, IETF54

    SIMPLE Working Group, IETF 54 0900-1130 17Jul02
    Chairs: Jon Peterson (
    Robert Sparks (

    Full Notes (taken by Dean Willis)

    Agenda presented, accepted

    MESSAGE Update, Ben Campbell

    MESSAGE method in IETF last call, waiting IESG feedback. There have been several
    small changes. This draft has added an option for large messages if
    congestion-safe transport is used. Also clarified Expires header, although new
    discussion of this topic has occurred on list in the last 24 hours. Use of
    0-value Expires as "immediate" request label is an open question vs "Priority".
    Audience poll favored current usage with 0-value. There has been discussion of a
    stronger requirement for REGISTER with method-message. Current discussion is to
    leave it as currently documented. Motion made from floor to leave well enough
    alone -- barring major issues, just go with the current form.

    CPIM Mapping, Ben Campbell

    Recent draft has minor changes to sync with 3261, but has CPIM dependencies.
    IMPP chair Mark Day reports that CPIM has experienced a resurgence of interest
    and may be the last deliverable from IMPP, with a due date on the order of "a
    couple of months".

    SIMPLE Data Manipluation Requirements, Jonathan Rosenberg

    Presence List Changes:

    Terminology change from "buddy list" to "presence list" in latest draft. More
    data than PIDF needed due to requirement for partial update, including
    full/partial update flags to allow differential updates. Lists may include
    lists, so the list server subscribes to list package for each entry rather than
    the basic presence package, thereby providing nesting.

    Open Issue #1: Should PL be a Template package? Discussion presented in slides.
    Open question -- is a new body type required? Current draft proposes a multipart
    body with a madatory base class and an optional seperate "collection" body with
    references to other elements. This preserves the original bodies in an
    unmodified fashion and allows package-indpendent collection servers. Example
    bodies presented in slides. Comment from floor: this has some similarity to
    SynchML and may justify examination thereof. Comment from floor: This
    multi-level approach is interesting, but the given approach has a lot of
    overhead. Also the proposal doesn't seem to have any way to distinguish multiple
    elements. 2nd comment adddressed, spec requires that templateable packages
    specify a URI to reference elements. Application/versioninfo should be an XML
    document with full referencing. Comment from Patrik: Mixing MIME dividers and
    XML dividers can be problematic, especially if signatures are used. Response:
    Reason author likes multipart/mixed rather than pidf is that this appproach
    preserves signatures and seems to work.

    Open Issue #2: Too Many Choices

    Current draft allows PIDF, PLIDF, Multipart Mixed, all of which have assorted
    issues discussed in slides. The Collection Template approach discussed above
    seems to allow mixing of these types while clearing all of the noted issues.

    Open Issue #3: State of Suscriptions

    The Presence List Server is a "fan-out" server. There's currently no way to know
    the state of the fanned-out subscriptions on a transitive basis. Proposal is to
    aggregate this information in listinfo format as proposed in collection template
    class, then support partial updates. Discussion: What would the event header
    look like? Proposed alternative: multipart/mixed with message/sip inside. This
    would reduce maintenance of collection formats. Response is that this would keep
    all of the overhead of SIP routing information -- cseqs, etc. and would create a
    great deal of overhead problematic for wireless applications.

    Open Issue #4: Sharing Of Versions

    Issues discussed in slides, all cleared by proposed collection model.

    Open Issue #5: Which Package does PLS use?

    Several options proposed: 1) presence.collection, fallback to presence, 2) add
    labels to lists so they can be parsed as lists 3) user has to KNOW that a
    subscribed list is a list, not an individual, 4) Server OPTION The URI to
    discover that it is a list, then uses appropriate package, which works as long
    as role of URI is fixed. 5) disallow recursion. Comments requested: Question:
    How are 1, 3 ,and 4 not complementary? Ans: Original proposal was "All but 2".
    This results in notifications that exceed the scope of the subscription, which
    could be confusing to sort out. Question: How do you identify these? The event
    header was "buddy list", what now? Ans: It was always a request URI, the only
    thing that changes is the event name. Question: Could the AOR be a bddy list?
    Ans: Yes, but not in an overloaded condition where the URI presents both an
    indivdual and a list. This would seem to be a reasonable interpretation of URI
    usage. Question: What about multipart recursion? Extended discussion followed .
    . . discussion deferred to offline. Question: If something has presence but not
    presence collection, would it be reasonable to serve up presence instead of a
    prsence collection? Ans: yes. This will be clarified in draft. Audience polled:
    Is going in the direction of a template class generally reasonable? Answer
    favorable, none opposed.

    Data Requirements, Jonathan Rosenberg

    Presence and IM systems use multiple data elements to drive the applications. We
    need to manipulate these data items, interact with, change, etc. them. This is
    disjoint from the subscription and notification mechanism, and includes read and
    write mechanisms with caching (offline access, and modification) and security
    requirements (listed in draft). Question: Does this create additional
    requirements around concurrent offline changes and reconciliation? Ans: Not a
    requirements issue but an implementation issue. Comment: This topic could use
    its own working group, we should perhaps not solve it here. Ans: We're just
    talking about requirements and really expect to reuse an existing solution like
    SyncML. Comment: Should study data model in ACAP very carefully. Ans: Authors
    are already working with ACAP author to analyze. Extended discussion on tradeoff
    of authorization, inheritance, and cacheing issues followed. Open issues include
    1) Do enough of the data manipulation type things we do fit under this model to
    justify further work, 2) Should we generalize or do something specific for
    presence lists? 3) How do we align with SIP conf work? 4) Should we adopt as a
    WG item? Comment: This is a large problem space, and includes things like
    WebDAV, XPath, XML database, and probably becomes at least a New York sized
    rathole. It probably would be a bad idea to choose to do something limited to
    the presence list problem. Comment: There's a lot of overlap with W3C and other
    work, we should collaborate. Comment: This is similar to the UA configuration
    task, can we combine them? Comment: Is this really a semantic manipulation
    problem, or a remove text editing problem? Comment: What is start with a pure
    XML framework, then we can use stuff like XPath and see if it works. Comments:
    We should at least work on this here, starting from specific topics in charter.
    Poll: Should this work be adopted as a wokring group item toward existing
    charter goal? Response favorable, none opposed.

    The PUBLISH Method, Sean Olson

    The critical issues here depend on the composition model in the preceeding
    discussion. The basic model is discussed in the slides. The contentious
    component of the draft is the "slot" model of presence composition. Open issues
    include: 1) Should we include CPL problem in scope, Proposal, No. 2) Is "slot"
    idea right way to go? 3) Do we need to standardize PType tokens? 4) Should PType
    require IANA registration? 5) Should PState be replaced with Expires header?

    Comments: This seems to be the micro-version of WebDAV, but scope-limited for
    just the PL problem. This may argue that the very general "PUBLISH" name is too
    broad. Also, do we really want to differentiate between hard-state and
    soft-state data? Ans: Name can be changed. Authors have deliberately restricted
    to soft-state because this data has direct correlation or "binding" with SIP
    routing and cannot be well addressed by other mechanisms like WebDAV. Hard-state
    information does not seem to have this characteristic. This is particularly
    crucial for third-party manipulation of soft-state information given only a SIP
    URI as a key to that information. SIMPLE isn't deployable without this and it
    has to be fixed NOW. The requirement here is scoped explicitly by SIP Events.
    Comment: Can we identify a reasonable stopping point? The model of having to
    find a "stopping point" based on a SIP URI seems reasonably common. Proposal:
    Could we do PUBLISH via a reversed subscribe/notify model? Discussion of this
    approach not favorable. Question: How does one manage policy of slot
    composition? Ans: The composition policy of a compositor is locally determined.

    3GPP Presence Requirements, Krizstian Kiss

    Slides summarize requirements. from draft. Discussion of requirememt "Keep all
    PUAs aware of each other's publishing": Comment that this seems to be
    contradictory, it would be better to make publishing transparent across devices.
    Ans: This is because we have "network attributes" that have to work this way.
    Further discussion deferred. Comment: there are requirements for filtering in a
    lot of our discussions, we should add to charter. Comment: partial notification
    is messy. We need to clarify this. For example, CPIM and partial notification
    are conflicting requirements. Comments on requirment for anonymous subscription:
    This means the subscriber is anoynmous, not that the subscription is invisible
    to the prsentity, right? Ans: yes. Comment: If geoloc is part of presence
    document, how does it get composited? Ans: simply -- just reference the geoloc
    document. There are lots of authorization issues around WHO can update and/or
    see geoloc. Discussion: Is it reasonable to accept requirement from 3GPP?
    Discussion: Rather than having "3GPP requriements" on our charter, shouldn't we
    simply integrate these requirements into our chartered requiremeents documents?
    This proposal seems to be generally favorable to the audience.

    3GPP Instant Messaging Requirements, Aki Niemi

    This document is intended as a "heads up" to IETF. The work is at a very early
    stage in 3GPP. Formal requirements are expected by IETF55.

    IMSX Protocol Evaluation for Session-Based IM, Mary Barnes

    Analysis presented. Comment: Although it doesn't currently support threading,
    BEEP could so so easily. Comment: Although there may be objections to
    implememnting yet another protocol in a node, SIP does shine at multiprotocol
    stories and really does work well with a mix of transports and codecs. Comment:
    The status of IMXP does not seem clear, as there have been apparent strategic
    shifts by the author (Jabber). Comment: Rohan said something about IMTP and
    strategic subsets and Fred Baker, but this reporter didn't parse it. Comment:
    messages are somewhat like media, and somewhat not like media, and we probably
    don't need a divergence between session and pager model. Comment: We seem to
    have only one proposal -- use SIP. The idea of defining IMTP as a seperate
    protocol subset seems pointless. Defining the session model as a stream of
    MESSAGES bounded by a dialog seems like the right thing to do. Comment: Using
    SIP without changing the name clearly violates the spirit and letter of our own
    SIP guidelines and has potential interop problems. Comment: If somebody is going
    to define a new proposal, they need to do it really soon. We really DO have only
    one draft under current consideration. Proposal: Let's just move forward with
    Jonathan's draft, in a non-exclusive sense. Discussion seems to favor this as
    the baseline default, and we can do additional stuff later if needed. We should
    immediately discuss on list and conclude whetehr we go forward immediately with
    SIP or a renamed SIP-subset (IMTP).


    MESSAGE Draft Status
    SIMPLE Drafts
    The PUBLISH Method
    3GPP Presence Requirements
    IMSX Protocol Evaluation for Session Based IM