Last Modified: 2003-09-16
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.
|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|
SIMPLE November 13, 2003 IETF 58
Session One: 0900-1130
Summary of major consensus points and action items: (All consensus points are subject to confirmation on list.)
(Thanks to Dean Willis and Vijay Gurbani for acting as notetakers)
Topic: Agenda Bash
No changes proposed
Topic: MSRP Open Issues, Ben Campbell
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
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
Changes since last version reviewed.
Noted that no comments received on list recently. Consensus: Move to WGLC.
Topic: Presence Capabilities, Mikko Lonnfors
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.
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
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:
Open issues from the list:
Query v. Path:
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.
Aki Niemi, Watcher info history
Background: 3gpp mentions winfo-history and some commercial
systems have similar functionality.
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.
(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.