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

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-26

Robert Sparks <rsparks@dynamicsoft.com>
Jon Peterson <jon.peterson@neustar.biz>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.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 design).

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, including for example 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.

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:
JAN 03  Submission of instant messaging session drafts to IESG for publication as Proposed Standards
JAN 03  Submission of presence list package set to IESG for publication as Proposed Standards
JAN 03  Submission of presence list auth/modify requirements draft to IESG for publication as Informational
FEB 03  Submission of requirements and proposed mechanism for event publishing to the SIP working group
FEB 03  Submission of CPIM mapping draft to IESG for publication as Informational
FEB 03  Submission of advanced messaging requirements draft to IESG for publication as Informational
MAR 03  Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard
APR 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-cpim-mapping-01.txt
  • - draft-ietf-simple-presencelist-package-00.txt
  • - draft-ietf-simple-data-req-01.txt
  • - draft-ietf-simple-publish-reqs-00.txt
  • - draft-ietf-simple-event-list-00.txt
  • - draft-ietf-simple-publish-00.txt
  • No Request For Comments

    Current Meeting Report

    Minutes: SIMPLE IETF 56  17Mar03 1530-1730
    Reporters: Dean Willis, Pekka Pessi
    Editor: Robert Sparks
     - Announced the impending SIMPLE Interop
     - Called for volunteers to host a SIMPLE Interim before Vienna
     - Consensus points
       * Publish - Handling hard state will be left to local policy
                 - HTTP vs SIP discussion does not belong in 
    requirements document
                 - Meaning of "tuple" is unclear and needs attention
       * RPIDS - draft (except ) accepted as starting point for charter item
       * isComposing - strong support to seek bringing this draft into 
       * Filtering and partial notification requirements - strong support to 
    seek bringing these drafts into charter 
    Notes reported by Dean Willis
    Chaired by Robert Sparks, Jon Peterson
    1530 Called to Order, Peterson
    Topic: Agenda Bash -- no objections
    Topic: Administrivia. 
    Revised charter pending. Reviewers needed for documents (Rohan 
    volunteered).  Interop event needed. Volunteer for hosting by Jasomi at 
    Banf or Calgary, 3rd or 4th week of April. Proposal for interim meeting 
    before Vienna. 
    Topic: Message Sessions, Ben Campbell
    History reviewed in slides. Message Session Relay Protocol (MSRP) work 
    attempted to resolve dependecy on co-media. Design work decided to 
    abandon co-media. Current draft is similar to  cpm-msg-approach but 
    addresses multi-nat scenarios, common firewalls, multiple IM sessions on a 
    transport session. Some co-media issues resolved around 
    bidirectional communications, and relay support. Note that this 
    protocol does not address relay discovery, but relies on knowledge in 
    endpoints. Note that in slides, all requests have hop-by-hop responses 
    except for SEND operation, which is end to end. 
    Open issue: ACK related bug in offer-answer, may address with UPDATE. Do we 
    need a refresh mechanism for BIND? There is also a race condition when 
    tearing down a session (between release and leave). Question re: 
    refreshing the BIND: Could we do one BIND instead of multiples using 
    crypto cookies ? (Send text).
    Open Issues: Need to fully define msrp URI scheme.  Do we needs msrps:?
    Open Issues: Security. Digest auth on BIND needs to be specified. 
    Question: What do we get out of having digest auth on BIND? Do we need an 
    msrps: scheme? Note that there are three identities here -- the user 
    identity, the server identity, or an alias identity. This 
    authentication is for protecting the "bind" side of the relay. 
    Currently, the "visit" side is not authenticated. Note that the usage of TCP 
    servers behind a firewall is no more secure than running a UDP server 
    behind a firewall. Further conversation to list.
    Topic: Publication of presence data: Jon Peterson, Sean Olson
    Requirements document broken off from mechanism document: Jon Peterson
    Open isue: Hard state requirements. Discussion defines "hard state" as the 
    default condition or absence of freshly published state. Question: Is 
    there a requirement for hard state? Poll: Should this be in scope of 
    requirements?  Argument: This is a matter of local policy on the 
    compositor function. So, "hard state" as defined here is just policy. 
    Audience (Henning): I agree that this is a special case of policy. Is the 
    manipulation of policy part of the requirements?  Question: Where does 
    discussion of HTTP vs SIP live?  Requirements, or 
    Publication mechanism: Sean Olson
    Changes since last draft simplified, now very much like "options" 
    request.  Added new out-of-sync response code and versioning 
    requirements, met by time-stamp of CPIM-PIDF. PUBLISH is now 
    non-dialog, soft-state, and logically scoped to a tuple. S/MIME is used for 
    privacy and integrity, and compositor must respect end-to-end security 
    requirements from the publisher.  Discussion: PUBLISH with an 
    expiration has granularity of the contained document, not individual 
    tuples. This might preclude composite of end-to-end protected tuples. 
    Issues: Need better definition of tuple. Discussion: This is one of the 
    most fundamental things to work on, but we argued against defining it in 
    IMPP.  Much discussion on definitions illustrated we don't have one. 
    Issue, do we need Facet header for authorization of tuple watching. 
    Question: Can we say that RPIDS is a better PIDF that people will 
    actually use? Unresolved. 
    Topic: RPIDS, Henning Schulzrinne
    Motiviation and overview given on slides. In short, a presence 
    information format for publication and notification. Adds device 
    capabilities.  Represents groups, with status within the group. 
    Suggestion that group representation be abstracted into a different 
    document. There is also an aspect of list composition functions that is 
    needed. Issue: label tag, which is similar to the pidf id tag but has 
    defined semantics on setting by presentity and applies to 
    publication rather than notification side. In short, there should be no two 
    tuples in the same presence document that have the same label. Issue: 
    elements, no discussion. Issue: what is a tuple.  Three models 
    presented: common AOR, generated by capability set, and contacts 
    representing devices (wityh privacy and duration issues). Proposed that we 
    document all three, but where? Comment: This does need to get resolved -- 
    can we get this nailed down by interim? Can we adopt this as a WG 
    effort? Poll: document seems widely-read. Given that, should this 
    document be a wg iterm reflected in charter? Strong consensus 
    Topic: IsComposing (istyping) state indication (vs idle): Henning 
    Slightly revised, open issues under discussion, poll to make WG status? 
    This will require deliverable add on charter. Poll to add 
    iscomposing to SIMPLE charter? Strong consensus shown. Comment from 
    future AD: Would like to have discussion of extensibility model. Comment 
    (Bon Wyman): There have been notifications of IPR on istyping. Can we work 
    around this IPR?  Comment from AD: Part of the WG's evaluation is around IPR 
    issues, so this discussion is valid, and consideration should be given to 
    the IETF's IPR declarations page
    Topic: Data Manipulation, Jonathan Rosenberg
    Point: This is general application data manipulation and is worthy of a 
    broader discussion. ACAP provides a model. Proposal includes 
    algebraicly scoped lists of lists-or-nodes. The ACAP data model seems to be a 
    good fit, bu the protocol itself has issues around persistent 
    connections, lack of intermediary support, underlying security 
    primitives (SASL), and syntax inconsistent with SIP. Discussion ranged 
    around comparison of ACAP attribute model and relationship to XML. 
    Question raised as to "why look at ACAP -- it's old" Comment: Could we use 
    WebDAV? Comment: The configuration work in SIPPING could probably 
    support this. Further discussion deferred to list.  Note that this basic 
    piece of functionality is a critical show-stopper for SIMPLE 
    Topic: SIP List Events, Adam Roach
    Revised as a full event class rather than as a template. Open issue: 
    filters, several points need review. Author requests review of the XML 
    usage (Sean Olson volunteered). Proposal for downstream forking example 
    received no objections. Needs more eyeballs. 
    Topic: Partial Notification Filtering, Hisham Khartabil
    Motivation and requirements presented. Proposed solution is XPath 
    expressions, leaving an open issue around triggering ("when", as opposed to 
    "what"). Poll: Is there a need for this sort of thing? Discussion: 
    Watcherinfo and others are using similar functions, so it is probably 
    useful. Discussion: Xpath may not have sufficient expressivity. Poll: Have 
    reqs drafts been read? Yes. Poll to bring reqs drafts onto charter, 
    mostly positive. 
    Topic: Partial Notifications Mikko Lonnfors  
    Defines requirements for partial notifications. Discussion: One 
    requirement is to "not change charging model" -- that's probably out of 
    scope for this WG. Poll: "go forward with this draft": moderately 
    positive, no negatives. 
    Notes reported by Pekka Pessi
    * interop
    * interim meeting before Vienna
      - call for volunteers/sponsors
    Message Sessions (Campbell)
    * draft-campbell-simple-im-sessions-01
    * MSRP
      - attempts to solve problems related with COMEDIA
      - lot like message sessions discussed in Atlanta
      - differences:
        - no comedia
        - handle intermediaries more explicitly
        JR: more than NATs, handling intermediaries within different admin 
        - supports common fw policies, where parties behind
     - problems with COMEDIA
       - no good way to match incoming connection to particular session 
       - NAT breaks COMEDIA usage of source addr and port
       JR: comedia uses port number as principal multiplexing 
    identifier, that cannot be used with intermediaries
     - implicit support for two or more relays
     - MSRP primitives:
      - BIND: establish session 
        - relay discovery protocol is out of scope
      - VISIT: associate connection with a session 
     - Host/Visitor:
     - diagram explaining host/visitor relationship
     - diagram explaining one relay case: host-relay-visitor case
     - diagram explaining two relay case: 
       - this is tricky
       - relays can establish connections between each other based on DNS 
    information from message uris
     - Open issues:
       - ACK-related Bug in o/a handling:
       - refresh mechanism for BIND
       - race condition when tearing down a session
     Aki Niemi: BIND only once, use a cookie to make difference between 
     Rohan Mahy: use soft state for BINDing
     - msrp: URI scheme
     - SDP encoding assumes that the host and visitor temp URIs have same 
     - Additional work needed for security
       - digest authentication
       - msprs needed for security?
      Jon Peterson: what are security properties we need?
      JR: relay wants to make sure that only a authenticated user may set up 
    binding on it?
      RS: use TLS to prevent anonymous usage?
      AN: what is the identity that is being authenticated
      BC: authentication is only between host and relay
      Cullen Jennings: do we need to authenticate visitor?
      JR: provide same level of protection as in COMEDIA, make msrp URIs 
    unguessable to prevent anyone from being a visitor
      CJ: make sure that no-one can use this to create a generic socket 
    server that can be exported outside firewall
       - end-to-end security
         - MIKEY, etc.
      RS: object very very soon on the mailing list if this draft is not on the 
    right path
    PUBLISH requirements
    - there is hard state and soft state for the presence
      * Requirements for hard state (or default state)
      * Use PUBLISH or something else to set the hard state
      * Hard state in or out?
      Aki Niemi: there should be such a concept; when you are out of the 
    coverage you should have somthing to deliver to subscribers
      Sean Olson: should hard/default state be CLOSED?
      RJ: the default state is a matter of policy, policy covers hard state
      Adam Roach: installation of hard state is out-of-scope of PUBLISH
      HS: this is a special case of policy, there should be mechanisms to 
    upload the default document
      SO: it is requirement for presence/publish system, it can be done with 
    data manipulation, too
      JP: should the default presence document contain a CLOSE tuple or may it be 
    empty without any tuples at all?
    - HTTP v. SIP discussion is out of scope of the requirement doc
    - updates from -01: 
    - was too complex, removed extra headers
    - added 494 Out of Sync
    - because removed headers, added set of requirements for the semantics of 
    the PUBLISH body (that are fulfilled by CPIMP)
    - versioning handled by the body ( for CPIMP)
    - no dialog
    - PUBLISH handles only soft state
    - PUBLISH is scoped to a tuple
      => each tuple can be manipulated separately
    - when end-to-end security (like S/MIME) is used, compositor must 
    respect that
    HS: we must be very careful with tuple-ids
    SO: publisher can handle each tuple separately
    JR: this is extremely PIDF-specific
    SO: this is only model that makes sense if you want to manipulate tuples 
    - Issues:
      - examples were missing Max-Forwards
      - definition of tuple is unclear?
      BC: important issue
      JP: each tuple is identified by an unique contact address of my PC?
      AN: (does a tuple contain a) contact address of you?
      Dean Willis: tuples are attribute-value pairs for presentity?
      - Do we need Facet header for authorization of tuple watching (ie. "Who 
    sees what?")
      AN: this is definitely a policy issue
     * richer presence information than basic PIDF
       - SIP-aware, translatable to CPIM easily
     * merged with cp-based documents for describing presentity 
     * Draft overview
       - Presence status
       - Timed status: new thing 
         - e.g., person was in a meeting an hour ago
       - Device capabilities
       - Allow presentity to represent groups
     * Problems:
        - groups can contain groups
        - at odds with list presence (but more efficient)
        - ok, ditch groups for now
     BC: agree
     RS: was going to ask pulling groups to a document of its own
     RJ: current list does not handle the combined status very well, the 
    status of the group is useful and should be kept
     * Problems:
       - PIDF has id tuple tag
         - allows handling of diffent tuples 
         - who owns each id? how to handle it?
     RJ: "id" is for receivers, something else is needed for composition
       - use "label" tag on backend side
       - also use something like css (which has id and class)
         - each element has two kind of identifiers
         -> enables policy filtering
     * Open Issues:
       - extending 
       - ortogonality: how to combile activities
      - What is a tuple?
       - AOR, custom address for each capability set, device address?
      HS: solicits comments
      JR: this is most important issue
      Brian Rosen: have a bar bof
      => Hum accepting this draft as working group item 
    * Bob Wyman: there is some IPR issues
    * Patrik Fältström: WG should take into consideration potential IPR when 
    processing a document, nothing more, nothing less
    Data Manipulation
    * manipulate buddy lists
    * manipulate authorization policy
    * examples
    ACAP (RFC2244)
    * generic mechanism for application-independent access to per-user
      application configuration data from multiple clients
    - Presence list with ACAP
    - Authorization policy with ACAP: requires defining processing logic of
      authorization entries, no need for scripts
    - Data model of ACAP is fine, protocol is bad
      - sasl (ACAP security model) is not compatible with S/MIME etc
      - no intermediaries allowed
    HS: has concerns with data model
    C. Huitema: why unearth this protocol? why not LDAP or SNMP?
    JR: take things that work, replace things that won't for use
    RM: use something that has a URI
    AN: document has two sides, nice datamodel and so-and-so protocol
    JP: split document? take it to list
    Presence Lists (Adam Roach)
    * take 3: an extension to sip-events
      - list contents as a multipart
      - meta info in xml mime body part
    * open issue: filters? do they apply to top-level list, the nodes, or 
    RM: do we need to take this to sipping?
    JR: we are chartered to do this
    Presence Filters (Hisham Khartabil)
    * eliminate unnecessary and unwanted notifications and contents
    * solution based on XML style sheets (XPath)
    JR: triggering stuff is needed (winfo) there is many different stuff going on 
    here filter can be generic, triggering probably 
    HS: while xpath can do simple arithmetic, semantics of triggering and 
    filtering may be different, xpath may not be enough, CPL-like approach 
    might be better?
    JP: motivation/requirements draft can be taken in charter
    Dean Willis: solutions documents might be better in SIP WG
    Partial Notifications (Mikko Lönnfors)
    * send only the modified parts to watchers
    BC: charging model? 
    ML: requirements coming from 3GPP
    JP: more reviewers needed for these drafts


    Message Sessions
    PUBLISH requirements
    Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol
    Data Manipulation
    SIP Event Lists
    'draft-moran, khatabil(2), kiss-...txt'
    Partial Notifications