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

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-16

Chair(s):
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 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
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
Internet-Drafts:
  • - 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-presinfo-deliv-reg-01.txt
  • - draft-ietf-simple-winfo-filter-reqs-00.txt
  • - draft-ietf-simple-message-sessions-02.txt
  • - draft-ietf-simple-pres-filter-reqs-02.txt
  • - draft-ietf-simple-xcap-auth-usage-01.txt
  • - draft-ietf-simple-xcap-01.txt
  • - draft-ietf-simple-xcap-package-00.txt
  • - draft-ietf-simple-xcap-list-usage-01.txt
  • - draft-ietf-simple-rpid-00.txt
  • - draft-ietf-simple-partial-notify-00.txt
  • No Request For Comments

    Current Meeting Report

    SIMPLE November 13, 2003 IETF 58

    Session One: 0900-1130
    Session Two: 1300-1500

    Chairs:
    Robert Sparks
    Jon Peterson

    Summary of major consensus points and action items: (All consensus points are subject to confirmation on list.)

    • MSRP will be split into a relay-less document and a document detailing relay use which will focus initially on multiplexing issues.
    • Partial Notification (draft-ietf-simple-partial-notify-00.txt) is ready for a Working Group Last Call.
    • There is a call to align XCAP/Auth with GEOPRIV. Analysis of this alignment must take place onlist in the immediate future.
    • Interest in expressing and using ad-hoc lists is intensifying. Analysis of the proposals brought to this list and SIPPING needs to take place in the near future.
    • Reviewers will be appointed for the filtering requirements drafts
    • There was consensus in the meeting to adopt the following drafts as working group drafts:
      • draft-lonnfors-simple-prescaps-ext-02.txt
      • draft-khartabil-simple-filter-format-01.txt
      • draft-khartabil-simple-filter-funct-01.txt
      • draft-isomaki-simple-xcap-publish-usage-00.txt

    Detailed Notes

    (Thanks to Dean Willis and Vijay Gurbani for acting as notetakers)

    Session One:
    Notes by Dean Willis

    Topic: Agenda Bash

    No changes proposed

    Topic: MSRP Open Issues, Ben Campbell

    Slides presented.

    Status reviewed.

    Issue: Shutdown of Relay. Does spec need discussion of clients reconnecting?

    Issue: Send Failures. If a SEND request times out on a tcp connection, is a resend likely to succeed? Consensus seems to be that this sort of failure indicates a dead connection, which should be closed and reconnected.

    Issue: Should there be a protocol failure message sent before closing the socket? Debate around whether it is possible for a slow-link transmission delay from a relay to produce a timeout on a SEND. Should a resend use the same TR-ID? Consensus: yes.

    Issue: In the cross-session (new INVITE) retransmission case, we have a question on the requirement for duplicate suppression, which would require globally unique TR-IDs, and require endpoints to remember TR-IDs across sessions. Do we need a mechanism to suppress these duplicates? No consensus, question deferred to list.

    Possible Major Issue: It is not uncommon for a TCP connection to get whacked by a NAT-binding reclamation. Currently, if this happens, we have to re-invite. This is probably not a reasonable design constraint and requires list discussion. The current BIND/VISIT semantics are problematic, as they clean up state in relays. One possibility would be to make the BIND protocol "stateless" and carry the entire connection info in it.

    Issue: Session Purpose. Current guidelines suggest a dedicated session for things like large content transfer. What keeps the other end from sending IMs on this session? Is a "one way" indicator (send only) adequate, or do we need a more semantic indicator? Seem to have consensus on send-only, with a small amount of clarification in the text.

    Issue: Session Teardown at Visting Relay. This needs to factor in the TCP-reconnect stuff, so connection is deferred.

    Issue: SEND for Keep-Alives. Currently, empty SEND messages are used to refresh the activity timer. Do we need another method instead of SEND? Suggestion made that a relay reset the timer whenever it sees ANY traffic, so any message, including a proposed "bodiless send with a new name" should reset the timer, effecting a keepalive. Question: Is bidirectional traffic required for keepalives? This raises the question of what happens in large-message conditions. Question deferred to list.

    Issue: Multiple Digest Algorithms. HTTP digest requires a seperate challenge per algorithm. Do we need to do anything other than this? Suggested that unless there is a very compelling reason to annoy the security people that we just continue to follow the HTTP model. Consensus to continue forward.

    Issue: Security considerations. We have several suggestions for improvements. Cullen is to send text on TLS usage. Question on whether we expect self-signed certs to work between relays (consensus, probably not). Also a suggestion that more attack scenarios are needed.

    Issue: MIME Usage. Action item: incorporate "normal" usage of MIME include Content-Disposotion.

    Issue: More Examples. Do these need to be in core MSRP spec or in a seperate example document. Suggested that we follow the SIP documentation model, but that more clarification of some of the existing text would help.

    Issue: Congestion. We have multiple TCP connections between relays. Is this a slayer of the commons? (Editor's note: The question is will having multiple connections cause traffic on other TCP streams to be treated unfairly). Does this need more discussion? (discussion followed). A "Large provider of IMs" reports that they have seen a requirement for connection reuse. Question: Is this related to congestion, policy enforcement, or TCP fan-out? Comment that we don't need an either-or solution. We have considered adding muxing later -- have we done anything to preclude it? Proposed that we split out relayance, or muxing, or relay muxing as seperate docs. Hum requested: Do people feel that relays without muxing are useful. Consensus yes. Poll on who will implement MSRP? About a dozen. Poll: Who will implement MSRP without relays. About six. Who would do relays with nat but no mux? About two. Who would do relays with nat and mux? About a dozen. Conclusion: Of the people who are willing to do relays at this stage, they seem to want muxing and chunking. Poll: should we rip out relays now, and do a seperate document for relays and muxing later? About a dozen. Should we continue as is? About 2. Proposal that we split up into core and relay docs, and set a hard date for deciding whether to include muxing in relayance. Noted that 3GPP seems to be using MSRP. Consensus: We rip out relays. Comment: This breaks TLS. Author thinks this is doable by the end of the year. Chair directs author to put a list of issues on the list ASAP, and to work with the relay-complainers on getting a list of relay requirements. Rohan volunteered to incorporate relay requirements into a draft.

    Topic: Presence Document Usage, Robert Sparks

    Slides presented.

    Issue: Can you associate a service with a tuple? Analysis by use case proposed, working from characterizing services by characteristics. Room indicated general support for current document and little interest in discussing it here at this time. Several people volunteered to send additional use cases. Proposed that we divide the problem into two 1)How to use PIDF, and 2) Representing specific servcies in SIP URIs. It may be that the "service" respresented by a SIP URL is not as clearly defined as the "service" represented by a Mailto. Proposed that this be resolved in the tuple referencing the service. Question: Will we include teletype use case? Ans. If you have a use case, send it in. Question: Will this be published as an RFC? This is currently an exercise in requirements and feasibility analysis. It might get published eventually by transformation into a call-flows document.

    Topic: Partial Notification, Mikko Lonnfors

    Slides presented.

    Changes since last version reviewed.

    Noted that no comments received on list recently. Consensus: Move to WGLC.

    Topic: Presence Capabilities, Mikko Lonnfors

    Slides presented.

    Changes since last version reviewed included harmonization with callee-caps and new XML schema.

    Issue: "<contact uri>" with prescaps -- what should be used? A contact? A GRUU? an AoR? This relates to the capability-merging model of callee-caps, but different. Consensus: AoR, representing union of capabilities.

    Issue: What capabilities? Conclusion: Publish as much as you can subject to privacy constraints.

    Issue: Contacting particular UA. Conclusion: Construct Accept-contact using prescaps.

    Issue: Syntax for negated featurs in lists. Options, !-notation, and "negated" parameter on feature element. Conclusion: use "negated" parameter. Discussion of content vs. attribute debate raised. Conclusion: ask an XML expert.

    Issue: Extension tags. Current mechanism requires a new namespace for extension tags. Typed extension parameter syntax proposed. Discussion taken to list.

    Poll: Adopt this work as a WG effort? Consensus to adopt noted.

    Topic: 3GPP Requirements, Aki Niemi

    Slides presented include must-have dates.

    No conclusions.

    Topic: XCAP Patching, Lisa Dusseault

    Slides presented discuss HTTP PATCH request which may be applicable to XCAP.

    Noted that either etags or locks must be used to prevent conflicts. This relates to the etags discussion around PUBLISH.

    Topic: Event Filtering Requirements, Hisham Khartabil

    Slides presented.

    Noted that reviewers who volunteered at last meeting failed to deliver.

    Topic: Event Filtering Format, Hisham Khartabil

    Issue: XPath Usage. Replaced in current draft with own BNF which is similar to a subset of XPath.

    Issue: Filtering by namespace. Added based on suggestions from last meeting.

    Issue: Applyling filters to domain. Unresolved. Needed for xcap-auth.

    Issue: Filtering scope is too large. Discussion: we could establish scope based on use cases. If we don't know of a tuple requiring a proposed filtering feature, we can descope it. Poll on adopting as a WG item? Generally favorable, consensus determined by chair.

    Topic: Filter Functional Description, Hisham Khartabil

    Issue: Full vs. Partial State. There seems to be confusion between the full and partial flags in the notification XML and the concept of filtering. These two things are independent -- the full/partial flag refers to the current view, and the current view is defined by the filter. Consequently, filtering does not mean that all notifications are partial.

    Poll: Who has read? Very small number. Debate on adopting as a WG document ensued. A hum indicated consensus to adopt.

    Session Two: Notes by Vijay Gurbani

    XCAP Jonathan Rosenberg

    Changes in main spec:
    Tried to get aligned with HTTP usage (a list of changes in the slide). Previous open issue: return content in error response to indicate what is wrong. Don't need it anymore and removed it. No questions from the floor.

    Open issues from the list:

    Filename:
    Does the xcap URI have a filename extension in it? Proposal: with filename extension. (No comments on floor).

    Mimetypes:
    What MIME type is indicated in PUT request and GET responses? Proposal: app/xml when it is an XML doc and text/plain for attributes. Adam: did you pick one or any reason not to use MIME type of the body. Jonathan: I don't think it matters too much. Adam: Reference the ad-hoc stuff we've been talking about on the wg list. Maybe we need a special MIME type app/xml-snippet. Jonathan: I am a little leery about this... Chris Neuman: You need to register an xml fragment. It's a fragment of an XML doc, so label it as such.

    Event package:
    What is the fate of this? Did not rev the doc much less discussion on wg list. Big question: integrate with SIP config framework? SyncML? Proposal: Move forward with important pieces of work (xcap, xcap- auth, xcap-list) and work on this later. People OK with this? (Some discussion between Rohan and Jonathan, but does not appear to be any objection).

    Etag scope:
    Current spec associates a separate etag with each XML component creating a dependency heirarchy. Problem: how does the client know what those other etags are? Proposal 2: Don't do it, maintain one etag. Proposal 2 is simpler ad list discussion indicated Proposal 1 had serious compliance problem to the spec. Recommendation: use Proposal 2. (No one objected and no other proposals).

    Query v. Path:
    Query appraoch is better for servers; path approach works better with existing implementation and hides implementation details. Proposals: path approach.
    Lisa D: If you have a URL with path elements inside a conceptual doc which is not compatible with webdav, I don't know what you would do with http when someone tries to present these URIs. It is incompatible with existing implementations.
    Ted: This should be permissible and implementable (disagree with Lisa).

    Error reporting:
    Current revision has no error reporting; however, there could be recoverable errors and how to indicate this? Question: can we put XML body in a 409 HTTP response?
    Lisa: Yes. You have to be careful, but extensions to HTTP do that.
    Ted: Will anything break if you include it? Probably not. But you should define in this extensions what the content disposition should be -- display it to the user, or treat it as garbage.
    Hisham: Is there an HTTP header like Reason or Warning that we can use?
    Lisa: No.

    XCAP list:
    Changes in this rev: is it an http extension or something else altogether? No consensus yet.
    Chris: Scheme name represents the app to me; http means hyper- text app. XCAP to me is a different scheme and should have a different port. Treat this as a different service. This is not accessing docs stored there, but modifying data. More sophisticated service than simple http.
    Ted: BCP 56 says you should not use http as a substrate for other apps. Generically we do not want http to be used for layered app, but you've been careful to construct this as an original application for http -- gets and puts. XCAP should be a usage of http.
    Lisa: It's a grayscale and a matter of judgement when it stops being http.
    Chris: I may be a little more conservative. I don't see this as something that a browser would render. If what you are looking for is code reuse, you can conceivably use the same http libraries but have them go to a different port. ???: Subdocument URIs are not what standard http server implements or client understands, regardless of it being on an http port.
    Aki: what is important is to keep the functionality 2616 and not invent new headers or whatever.
    Ted: Do you see the development of this long term not being backward compatible with http as a whole?
    Jonathan: Need to work more on wg mailing list.

    XCAP auth:
    Axed this document seriously for simplification.
    Open issues: alignment with geopriv and lying/polite blocking.
    Geopriv is working on the same problem: geolocation and presence are intimately related. We use PIDF doc to carry geoloc info right now. In RPID there is a PLACETYPE element which can be used as a start. Industry looking for geoloc and presence as a service.
    Rohan: Also enhances the IMPP value proposition. Are folks interested in actively aligning geopriv and simple wgs in how they represent data? What do people think?
    Adam: I see the value but from a practical viewpoint I see a hard time putting together a solution that does not include exceptions.
    Ted: I see a great value; folks who want this would prefer them to use the same system. Presence is one of the most critical use of geoloc resources. So, yes, I would like them to align.
    ???: In favor of this approach. Need to deal with some technical and document issues.
    ???: In 3GPP device, geopriv is somewhat of an unknown and simple is more prevelant. If we get this aligment done in IETF would that result in any gains outside?
    Robert: Group is interested in learning what alignment would mean. Let's move on now.

    Issues: exceptions need to be treated carefully. Can't use them for a pure blacklist. Exceptions don't deny a user permissions - they allow a conveinence for enumerating a long list of people to whom a rule applies.
    Ted: geopriv wants exceptions to work. Problem is a timing one. If geopriv does not get its work done by the close of this year, it'll be a lame duck. geopriv has a slightly different problem: group membership has to be resolved.
    (Long discussion ensued on exceptions. Issues include federated service providers, users in an enterprise, issues of accessability of lists from providers, revocations, white lists and black lists, etc. Chair interrupted since the discussion went out of time.)
    Conclusions: can't draw any right now. Jonathan to post the slides and continue thrashing out the issues on the SIMPLE mailing list.
    Robert: This is a hi-priority discussion that we need to close in 9 days max!

    Aki Niemi, Watcher info history

    Background: 3gpp mentions winfo-history and some commercial systems have similar functionality.
    Jonathan: What is the use for this? I have authorized you to watch me anyway. Why would I want to know that you were watching me for 2 hours. Massive amount of data generated.
    Jon: We would like to see the motivation before accepting anything as a requirement.

    Orit Levin, Ad-hoc resource lists using subscribe

    Motivation: solves an acute problem of batched notifications by introducing the RLMI schema. Cannot be deployed in an interoperable manner wihout standard creations of 'soft' or 'hard' lists.

    The ad-hoc list dynamically created and modified by a watcher. The list creates a soft state in the RLS and exists only for the life-time of a SUBS dialog. NOTs are being sent in any agreed format (PIDF, ...) The proposed solution: new option tag: adhoclist and new Media type name: application/addrl+xml *Went through a call flow; see slides, slide number 5-9)

    The solution relates to draft-camarillo-sipping-exploders-solution-00.txt. However, this I-D is classified as being in a B2BUA. It is an excellent case study: longtime identified reqs, technically straightforward and no new security risks.

    Proposed next steps: define as a WG working item in SIMPLE, if accepted start polishing the spec details on the list, and the standardization timing is crucial.

    Robert: Related proposals to this that arrived from many different directions. Group is ready to start exploring this space. But we are not ready to adopt one document as a wg item right now. Let's have list discussions first. It's getting list attention and let it continue for a couple of weeks and revisit this again.
    Adam: In many places in your presentation, you mentioned a series of requirements that are not met by the existing solutions, such as XCAP. Is there a specific requirements document you had in mind? I propose that we need to figure out what requirements are not met by existing proposals before we continue down this path.
    ???: Can we work this in the SIPPING WG where we are pursing a more general solution?
    Hisham: problem not specific for subscribe.

    (Further discussion directed to list)

    XCAP Usage for publishing presence info, Markus Isomaki

    Motivation: Every device publishes its state independent of other devices. Each devices cannot access the publication state published by others. There is need to be able to publish PUA/device indepedent data about the presentity. It must be possible to fetch and update this data from any device. Examples of this data: presentity's home page.

    Why XCAP? allows manipulation of data on a server. SIMPLE presence apps already use XCAP to manipulate lists.

    What the I-D specifies: define a new AUID: presence-publish. PIDF XML schema and its extensions (RPID, CIPID, Prescaps, ...) No computed data or additional constraints.

    Open issues: how to publish content which is external to PIDF? (images, logos?)

    Proposal: use CID URIs, upload external content via HTTP, insert http URIs to PIDF doc, ...

    Ben: This is an open issue that applies to publish and notification in general.

    Next steps: adopt this as a wg draft?

    Ben: change name of I-D.

    (Hum taken to establish this as a WG doc; hum indicated support).

    14:50 Meeting adjourned.

    Slides

    Agenda
    Message Session Open Issues
    Presence Document Usage
    Partial Notify
    PreCaps
    Wireless Requirements
    Document Patches
    XCAP
    Event Filtering
    Watcherinfo History
    Ad-hoc Resource Lists using SUBSCRIBE
    XCAP Usage for Publishing Presence Information