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

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC 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: 2004-09-29

Chair(s):

Robert Sparks <RjS@xten.com>
Hisham Khartabil <hisham.khartabil@nokia.com>

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 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.
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
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

Internet-Drafts:

  • draft-ietf-simple-event-list-06.txt
  • draft-ietf-simple-message-sessions-09.txt
  • draft-ietf-simple-xcap-04.txt
  • draft-ietf-simple-xcap-package-02.txt
  • draft-ietf-simple-xcap-list-usage-04.txt
  • draft-ietf-simple-rpid-04.txt
  • draft-ietf-simple-partial-notify-03.txt
  • draft-ietf-simple-partial-pidf-format-02.txt
  • draft-ietf-simple-event-filter-funct-03.txt
  • draft-ietf-simple-filter-format-03.txt
  • draft-ietf-simple-prescaps-ext-02.txt
  • draft-ietf-simple-cipid-03.txt
  • draft-ietf-simple-future-02.txt
  • draft-ietf-simple-iscomposing-03.txt
  • draft-ietf-simple-presence-rules-01.txt
  • draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt
  • draft-ietf-simple-msrp-relays-02.txt
  • draft-ietf-simple-presence-data-model-01.txt
  • draft-ietf-simple-partial-publish-01.txt

    Request For Comments:

    RFCStatusTitle
    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

    Current Meeting Report

    Minutes - IETF61 - SIMPLE WG meeting - Washington, D.C.
    (SIP for Instant Messaging and Presence Leveraging Extensions)

    Summary:

    MSRP:
    Several changes were made in response to Sam Hartman's security review. The group is comfortable with those changes. The number of open issues is rapidly decreasing - we expect these drafts to be last-called after thier next revision. The chairs will obtain appropriate review of the drafts use of SDP.

    Presence Rules:
    The group extensively discussed what it means to allow rules based on anonymous or unauthenticated identities. No specific decisions were made during this discussion.

    Partial PIDF:
    The group noted the similarity between the differencing mechanisms in this draft and the mechanisms in XCAP. There was consensus to work towards a common mechanism.

    Partial publish/notify:
    Draft will be clarified with guidelines on when to use the partial mechanisms.

    XCAP:
    The group rejected a proposal to allow idempotency tests other than GET(PUT(X))==X. Jonathan will make minor revision to the core draft which will then be ready to submit for publication.

    Presence Data Model:
    The group reached consensus that the model must provide a way to pass potentially conflicting information through a compositor without losing data. The group concluded that the algorithms for applying composition and selecting policy rules will be different. There was extensive but inconclusive discussion around differentiating services (tuples) based on URI equivalency.

    Raw notes from each session follow:

    -----------------------------------------------------------

    Notes, SIMPLE First Session, IETF61
    Reported by Dean Willis

    Agenda bashed.

    Status of various drafts presented on slides. Noted that "is composing" is in RFCED queue, not IESG queue.

    Topic: MSRP
    ------------------------------------------------------------
    Discussion lead by Ben Campbell
    Slides presented.

    Changes since last pub and dependencies reviewed.

    Changes from security review:

    Added applicability statement around usage with rendezvous/negotiation protocols.

    Mapping of "im:" URIs. This needs to be in a separate document. Dicussion ensued as to whether MSRP blocks on this document. The general consensus is that it does not, as MSRP never sees an "im:" URL (this would be a rendezvous dependency).

    Security review suggested reintegrating core and relay drafts. Consensus seems to be to resist that suggestion. Suggested that the full security story needs to be in one of the two drafts.

    Previous deaft missed RFC 3682 Application Considerations on usage of CPIM headers. This has been clarified.

    Open issues:

    "?" Parameter Syntax: Proposed that this be added to the next rev. Discussion: Cullen has a concern that this may break the security model and will review offline with author to ascertain.

    Overlapping Chunks: Concluded to recommend that most recently received chunk wins unless the application domain dictates otherwise. No arguments raised against proposal.

    Report handling: Consensus among authors that current draft is underspecified. Proposed that negative reports be "per chunk" and new incremental values for Report-Success (as well as per-message) be permitted. No argument raised against proposal. Further: Relaible delivery requires positive Report-Success or incremental, Report-Failure allows rapid failure detection (along with normal failure timeouts). This would require requesting both success and failure reports at session setup. No argument against proposal. Further: Proposed that spurious reports be silently dropped. No arguments araised against proposal.

    Discussion: Does Section 8 (O/A, SDP Ext.) need to be reviewed elsewhere? This includes some a-line attributes and fmt, and that sdp-new requires a more detailed registration process. We may also need to register TCP as a transport. Task: Chairs will work it out with other chairs and ADs. Note: TCP has been registered as part of comedia.

    Discussion: Have there been any implementations? One report of preliminary implementation experience, on which the developers had "serious heartburn", primarily around the abnf that was supposedly fixed in this release. One other concern was raised around handling the closing -- given the structure, one can't detect flow end strictly by ABNF, and list consensus was to stay with this.

    Discussion: Is the flow control built into MSRP justifiable? If so, then we need a relay push-back capability to handle buffer-overflows. This interacts with "many-flows onto one-TCP" plexing, and providing reordering of chunks. Argued that reordering is required anyhow, so this is no added complexity. Conclusion is that the current text seems consistent with our understanding of requirements.

    Discussion: Similar SDP-ish stuff is being described in BFSCP. Should we unify? Concluded that the authors will get together and discuss.

    Further discussion on implementation: Implementors seem to be deferring deployment until the RFC is published. This view is supported from experience reported in 3GPP about their attempt to use MSRP.


    Topic: MSRP Relay
    --------------------------------------------------
    Discussion led by Cullen Jennings
    Slides Presented

    Noted that we need one example in text. Other than that, there have been no comments on-list.

    Poll: Who is planning to implement MSRP base? (Many, app. 40). Who is planning to implement MSRP relay (much smaller, app. 9).

    Poll: Who plans to read and comment during last call (very many, 1/3 of room).



    Topc: Presence Rules
    ---------------------------------------------------
    Discussion led by Jonathan Rosenberg
    Slides presented.

    Slides review changes from previous version.

    Discussion of anoymous: Seems to be a desire to differentiate an "unknown user" from a "user authenticated to the network who prefers not to disclose". Is a non-authenticated "From" identity not the same as anonymous? How does this relate to Caller IDs "Anonymous" vs "Unavailable"? Is there a need to present anything relative to the strength of authentication used? Proposed: no plan to add an "authenticated" condition. Unauthenticated identities will be considered comparable to "unknown". Local policy will determine whether any specific authentication technique counts as "authenticated", and techniques below this threshold would be counted as "unknown".

    Proposed that we may need a way to match "any" identity in a rule.

    More discussion.

    New proposal: Delete special treatment "for authenticated but anonymous" and consider all non-revealing identities "unknown".

    More discussion.

    Point: Unauthenticated should NEVER receive more information than "authenticated but anonymous".

    Editor: Why does nobody seem to understand that this is a two-axis system? Axis 1 is "Authenticated vs. Unauthenticated", and axis 2 is "Presenting vs Not Presenting Identity", and that decisions need to be made for at least three of the four resulting tuples?

    No conclusion noted.

    Changes since last rev reviewed.

    Several issues drew brief discussion with some suggestions of discussing offline.

    Discsussion returned to identity, the uncertain, and the unknown. The result was unclear.

    -----------------------------------------------------------------------
    (Note that we were fortunate enough to have two notetakers for the second session. Both sets of notes appear here)
    -----------------------------------------------------------------------

    Notes, SIMPLE session two, IETF 61
    Reported by Ben Campbell

    ------------------Partial PIDF format 02 (Jari Urpalainen)

    --"patch" model for pidf docs.

    add, remove, replace, but no creation.
    failure falls back to unchanged pidf doc.

    question: similar to xcap operations--how close is the relationship?
    answer: very close--same operations that any xml database uses.

    issue: this is a compression scheme on xml docs, based on diff. We should have one way for all xml docs, not one for each. similar to xcap

    Further discussion about competing with xcap, and which is more simple and/or compact.

    Issue: Is this just xcap with different attribute names?

    Jonathan agrees to look at possible improvements to xcap.

    Chair: Both this and xcap took divergent evolutionary paths to a similar place--no competition intended. Need to talk to other groups working on xml diff formats.

    --------------Partial Presence (Aki)
    *-partial-publish-01
    *-partial-notify-03

    Radical simplification
    No longer tuple specific.

    Issues: What if updated version is garbage?

    Issue: Do we need guidlines to avoid sending partial pidf that is bigger than whole doc. Don't want to do a large number of small changes.

    Resolution: We think it is already addressed in draft. (Maybe just notification, but needs to be in publish.)

    ---------------------------XCAP Needed diffs (Jonathan)

    Issue: xcap equates get(put(x))==x as idempotency. This is sufficient but not necessary. ( if-match requests are all idempotent)

    Options: Clarify, but keep normative text; allow other idempotent ops.
    Proposal:Keep normative text.

    discussion: does get(put(x))==x also check for concurrent changes?

    Resolution: accept proposal.

    Issue: xcap list usage talks about unioning liest elements. But operation is more complex--ns prefix can get lost. (see slide for accuracy)

    Proposal: when <service> element copied into global doc, add a namespace prefix def for all in-scope ns. If default differes from global def, add a new default.

    Resolution: accept proposal.

    chair: draft already last called, need to post changes on list.

    ----------------------------Presence Data Model Open Issues (Jonathan)

    Topic: One element vs many. Currently only one person element. Only one definition for any one device or service.

    question: do we allow multiples? Represents unresolvable conflicting info at compositor.

    Jonathan and Henning present arguments for each side.

    Comment: Need ability to be lossless.
    Comment: Both models may be needed.
    Comment: No _practical_ one best composition policy.
    Comment: Need something deterministic to publisher and watcher.
    Comment: Even an endpoint can publish conflicting information.
    Comment: Can we have a way to show a "preferred" view of data for dumb consumers, but also show raw or conflicting data for smart consumers? This requires some form of metadata.
    comment: want to do something today that allows complex solutions in the future, but not necessarily solve all the hard problems now.

    Resolution: Need the ability to avoid loss and express conflicting data. This will come with some complexities. Will not try to specify all complexity up front, but want to specify some method of specifying a "preferred" instance out of a conflicting set.

    Topic: Spheres- for variables that serve as rule selectors (e.g. sphere) into privacy policy, need to determine which is used. Composition output and rule selection are logically distinct.

    Proposal: Allow separate algorithms for rule selection and composition. Selection algorithm could be local policy, or a standardized algorithm.

    comment: composition could include conflicting spheres.
    Comment: we need to discuss atomicity of conflicting info.
    comment: determining sphere priority is policy decision.
    comment: May need to select included in composed document.

    Resolution:

    1) Composition and selection algorithms are separate.
    2) Selection algorithm is application defined for now, but we may need to define a default in the future.

    Topic: Multiple services with same URI

    Do we need different identifier, but with same contact ID. What if pua publishes multiple serices with Contact containing AoR?

    How do you identify conflicting services vs just different services?

    How about different services at same device with same URI? Example of one softphone doing voice and IM, currently available for IM but not voice.

    Discussion about whether this is a capabilities problem or something else.

    We appear to have very different views of what service means, before we can determine encoding.

    Call attention to henning point: Differentiating tuples based on URI equiv. Do compositors group things into multiples based on URIs. But can compositors cannot canonically compare all URIs.

    Attempt to call question:
    1) What is interpretation of two tuples with same contact URI
    2) Should we force a composer to remove and compose multiple tuples with the same URI if it can tell?

    Resolution: None--take it to the list.

    -----------------------------------------------------------------------
    (Note that we were fortunate enough to have two notetakers for the second session. Both sets of notes appear here)
    -----------------------------------------------------------------------

    Notes, SIMPLE Second Session, IETF 61
    Reported by Dean Willis


    Topic: PIDF Partials
    ----------------------------------------------------
    Discussion led by by Jari Urpalainen
    Slides presented

    Comment: There would be a benefit to having some sort of XML compression and partial scheme that would work across applications. Discussion followed on this approach vs xcap diff. Author maintains this approach is shorter and should replace xcap diff. Suggested that there should be comparisons made with real messages.

    Comment: It appears that the net effect is that we have different XML element names.

    The previous proposal worked on the element level, whereas this approach is doing more of a syntactic patch.

    Consensus: We should settle on one technique -- this or XCAP diff, or whatever. Noted that XCAP diff is already a WG document, so we should study this approach and see what, if any, makes it better, then add that to xcap diff.

    Chair commentary: This is the result of convergent evolution, and we should take this to the list for convergence. We do still have a need for partial notification. We should also check with people outside SIMPLE who are doing XML diffs.


    Topic: Partial Presence
    ------------------------------------------------------
    Discussion led by Aki Niemi
    Slides presented.

    Goal: A small change in presence should produce a small NOTIFY.

    Noted that this technique should work for any event package using XML bodies.

    Observed that sometimes, for a very small document, a partial update might be larger than a full update due to the extra syntax. It was discussed as to whether the draft has adequate guidance on "when" to use the partial format.


    Topic: XCAP Needed Diffs
    -------------------------------------------------------
    Discussion led by Jonathan Rosenberg
    Slides presented.

    Issue: Noted that draft needs to clarify usage of term "idempotency". Discussion of this term and usage followed.

    Issue: Namespace prefix definitions. Fix proposed in slides. Discussion: Could this lead to a collision? Ans. No, the prefix definition is at the service element itself.

    Conclusion: Author will submit a revised draft.


    Presence Data Model Open Issues
    --------------------------------------------------------
    Discussion led by Jonathan Rosenberg and Henning Schulzrinne
    Slides presented.

    Issue: One element vs. many. Current system does not allow conflicting data. It has been proposed tha twe allow multiple service elements, representing conflicting input to the compositor, allowing the watcher to decide.

    Proposal: Stay with existing system (argued by JDR). This generates issues for automata as consumers of services. This may also lead to multiple ways of interpreting conflicting data vs. simultaneous capabilities, and could be problemactic. This also requires adding a tuple/element identifier, and may need lots of additional metadata to make the interpretation feasible. Alternate approach would be to add a "<conflict>" wrapper later.

    Proposal: Add support for many elements (Argued by HGS). Most existing presence systems have only once source of presence data. They don't need to do multiple elements. However, we are now building multisource systems, and need multiple elements to meet additional requirements listed in slides.

    Noted that one could add a "<view>" or "<conflict>" wrapper now, to accomplish something similar, but that if it is added "in the future", we will have a major backward compatibility problem.

    Disussion follows . . .

    Observed that conflicting data will occur -- the Question is how to deal with this. Is there really a correct composition of this data, or is there a consumer decision that is needed? We probably have a need to support delivery of both "vest guess" composition AND full data to consumers.

    Observed that we may not know how to do the "best" composition in all cases, and therefore probably need to be able to expose uncertainty to the watchers.

    Observed that it may be important that the publisher understand what the compositor is going to do with its data. This may lead to a need for source-expressable composition preferences, which is hopefully a "future" topic.

    Proposed that we need to support both models.

    Proposed that HGS' model would benefit watcher-specific composition.

    Noted by chair: This means that an "original source" could publish conflicting information.

    Proposed that the presence document should be able to indicate the "preferred" view among conflicting views, and that this would be usable by "dumb" clients. Also noted that "outgoing" policy might dictate which view is shown to any given watcher.

    Proposed that there is no "one true answer" for composition.

    Proposed that a timestamp is not enough to indicate the "preferred" element out of a compositor.

    Chair summary: Not acceptable for us to produce a lossy model. We want the ability to pass through additional information. We understand that this increases complexity. We will not explain everything, but will provide a hint as to to which one of the conflicting elements is recommended.


    Issue: Sphere

    If we have multiple elements, we may have conflicting sphere information. This breaks the current model of using the default composition policy to select which authorization policy applies.

    Proposal: Allow separate algorithm (not same as default composition policy) for determination of which conflicting variable is used for authorization policy.

    Much discussion followed.

    Proposed that perhaps authorization policy should be driven by the view that would be seen by the presentity as a watcher.



    Issue: Mutiple Services with Same URI

    Much discussion followed.

    Noted that there are deployments that don't support GRUU and that some are hestitant to make the solution GRUU dependent.

    Noted that "Open" and "Closed" at a top-level are inadequate as soon as there are multiple capabilities per device.

    Discussion devolved into an apparent divide between model views.

    Chair point: We keep talking about differentiating tuples based on URI equivalency, and whether compositors group according to these same comparisons. This necessitates that compositors be able to ascertain the equivalency of two URIs, which might be difficult. We appear to have no consensus on this at thsi time.

    Summary: This is going to make a long list discussion, and we may not have even stated the problem clearly.

    Slides

    Agenda
    MSRP Again!
    MSRP Relay
    Presence Rules
    Partial PIDF format-02
    Partial Presence
    XCAP Needed Diffs
    Data model and RPID