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.
| Mar 01 | Submission of Extensions for Instant Messaging to IESG | |
| May 01 | Submission of Extensions for Presence to IESG |
Current Meeting Report
SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions
Minutes - 12/12/2001 1300-1500 MDT - IETF52
Chairs:
Jon Peterson - jon.peterson@neustar.com
Robert Sparks - rsparks@dynamicsoft.com
Summary:
Charter and logistics
* An update to the SIMPLE charter has been submitted reflecting the SIP/SIPPING split, the proposed SIP change process, and the watcherinfo/CPIM mapping deliverables. Publication has been tabled pending outcome of disussions in SIPPING (see the SIPPING minutes)
* MESSAGE has been handed off to SIP - currently scheduled for last call in May. Brian Rosen will work with us to move that call to an earlier date
draft-ietf-simple-presence:
* The presence draft will be modified to rely directly on sip-events, which will in turn rely on sip-bis instead of 2543. The result will be shorter documents with less opportunity for unintentional contradiction.
* We will provide Alerts (notification with indirect content). Primary remaining issue: Lifetime of URI in an Alert. Both the sip-events and presence drafts will have to change to reflect this.
* There is consensus to establish a presence subscription dialog based on the first arriving NOTIFY or 2xx response to the SUBSCRIBE
* There is consensus to leave the current forking text as is. Subscribers SHOULD accept only one NOTIFY. If merging is required, the burden lies on the subscriber.
draft-ietf-simple-winfo-package:
draft-ietf-simple-winfo-format:
* Proposed recent format changes accepted with the additional removal of most-recently-subscribed
* Sip-events and the format draft will reconcile the descriptions of reasons for terminating subscriptions
draft-mankin-im-session-guide:
* Hum against taking this on as a SIMPLE work item. Opinion was that work on the draft should continue in the transport area
* SIMPLE group urged to internalize its guidelines
* Applicability of the requirements being placed on OPES wrt intermediary discovery and disclosure needs to be discussed
draft-rosenberg-simple-im-transport:
* Weakly expressed support. Moderately strong hum against proceeding with this proposal.
- concerns over keeping IMTP and SIP syncronized
* Alternate proposal solicited - if none appears before early January, work will proceed with IMTP
* Split opinions on whether a proposal must be held to mankin-im-session-guide
---------------------------------------------------------------------
Full Notes (thanks to Brian Stucker - bstucker@nortelnetworks.com)
Charter Updates:
Have submitted a new charter.
* Charter resubmitted a couple of weeks ago
* Now reflects SIP/SIPPING split and proposed SIP change process.
* Presence 'extension' deliverable now 'event package and related protocol mechanisms'
* Presence publication tabled in SIMPLE, currently considered in SIPPING.
* Dec 01- Presence event package, watcherinfo, CPIM mapping.
* Jan 02 - Messaging drafts
Transferred deliverables
* Draft-ietf-simple-im-01/draft-ietf-sip-message-00
- Status (any SIP chairs want to speak to schedule?)
- SIP drafts page say May 02 - be nice if that could be moved in a bit.
* Brian Rosen: Drafts dates are based on logistics problems. We can move it up if we can get the draft ready, get reviewers, list comment, etc. But we can move it up if there is a need?
* Jon: Would be nice if we could have this in the first quarter?
* Brian: We'll look into it.
* Draft-donovan-publish-requirements-01
- An actual proposal discussed in SIPPING yesterday.
- Clear that SIPPING will only do requirements for publication.
* Where will it go from there? SIP WG?
* The IETF would like to do the right thing, and not get too rule bound. Hope is that the same people will spend some time in SIPPING and make sure that the right approach is formed. The method document has to come out of SIP.
* SIPPING needs to look at the problem of whether or not we need a new method.
* Question begs, is presence publication urgently needed in SIMPLE, and that needs to be looked into.
------------------------------------
Presence Open Issues:
* Open issues in presence-04
- Dependencies and duplication
* Currently
- Rfc-2543 <- sip events <- presence
- Problem is that sip events is duplicating text from bis-05.
* Can we simply make sip events dependent on bis, thereby shortening it.
- Presence is duplicating text from sip events.
* Proposal
- Bis <- sip events <- presence
* Bis is nearing completion so timing is not going to be much different
* Requires cleanup of redundant text across all three documents in progress. This will be done.
- Alerts
* Would be nice to only be notified of change in presence, not actual presence.
* Actual presence could then be fetched with HTTP
* Why is this useful?
- Large presence documents wouldn't get fragmented.
- Large presence docs could be fetched when time is good (ie. Not in a call).
* Details
- SUBSCRIBE would have Accept header indicate support
- Presence of application/uri-list
- Still have to support application/cpim-pidf+xml
- Etc
* Issues with Alerts
- Broader than presence. Probably belongs in sip-events
* Presence would then state that its allowed.
- Security issues
* Just because SIP can be authenticated, doesn't mean HTTP can.
- Transitive trust vs. e2e
- Henning brought up concerns on this.
- HTTP SIP interactions
* Requires a way for SIP server to manipulate content on web server.
- Henning brought up concerns on this.
- Duration of URL validity
* Need to specify - presumably subscription duration.
* Proposal
- Really useful, really simple
- Add to sip-events and presence.
Henning: Similar to web server problem.
Jonathan: does require an interaction between HTTP and SIP; don't have to do it.
Henning: Must specify something that will work well.
Brian: Doesn't have to be HTTP, could use other mechanisms.
Jonathan: Must develop a baseline.
Call for opinions:
Sean: I don't see this as a major issue, or a hard thing to do.
Adam: I'm in support for this, I don't see a problem. The issues that Henning brings up are not completely trivial, but they're easy to take care of. Can be added to sip-events, but doesn't see a need.
Rosenberg: Wants a general mechanism the same across all packages and to specify behaviors. Need to specify the duration that the presence URL is good for.
Sean/Rohan: Don't go into such detail about the implementation.
It's unimportant how long the document sticks around.
Henning: We need to make sure that the semantics are complete and equivalent.
Brian Stucker: Agrees that need to specify amount of time for URL to be valid, just as there is one for subscription. Interval doesn't need to be specified.
Sean: There's no guarantee that the semantics are equivalent.
Adam: This sounds like the argument about how to encode a piece of content versus what it means.
Rosenberg: This is an automata that is processing this URL, so it needs to have an idea of how long the URL is good for.
Jon: Is there any value in leaving this URL open for our application?
Rohan: I don't think that's what Rosenberg is proposing.
Diana: Likes the consistiency. Does this trickle to general SIP?
Henning: The semantics that we are arguing about here are buyer beware problems. This is a presence document, versus this document is not going to be around after a period of time. We wouldn't specify that this is a presence document, we're specifying other attributes.
Adam: I don't have a problem with the proposal, but it sounds like the semantics of the usage should be in the presence document.
Jonathan: Need to specify what URL means and have well-defined semantics to work.
Henning: sending a JPEG isn't particularly useful.
Sean: Your implementation has to handle it - doesn't need standardization.
Adam: How is content encoded Vs. what does it mean?
Jonathan: Wants to define what it means when you return a URL. It's important to remember that a person isn't using this URI, an automata is.
Andrew: This is like W3C semantic web problem.
Jonathan: Disagree - not solving that problem
Jon: What do we want the Presence URI to mean?
Rohan: That's not what Jonathan is proposing.
Henning: 2 issues: what are the time properties and what is the content. In events, this would not be a presence document.
The semantics being argued are hints to the implementor - these are the semantic expectations. Agree that semantics need to be specified.
Jonathan: Most web browsers accept *.*. This URI should be very specific and have full semantic content, unlike normal web request.
Rosenberg: Presence package would say that this is a one-shot document, etc.
Conclusion: Continue discussion on the list.
- NOTIFY/200 Race condition
* ASSUME you want to only accept one NOTIFY
* Sip-events says you should accept the one that matches 2xx to
SUBSCRIBE.
* Proposals
- Buffer NOTIFYs until 2xx, then 481 all that non-matching ones.
- Accept all NOTIFYs, when 2xx arrives, refersh all non-matching.
- Accept first NOTIFY
* SUB 2xx is ignored
- Accept first message
* SUB 2xx if its first
* NOTIFY it its first
* Probably also an issue for sip-events, not presence.
- Forking
* Definitely the biggest issue.
* Some problems are not presence specific
- HERFP
* Proposal
- Keep what's in the document. If they need aggregation, then put a point in the network and leave it be.
- If there are multiple PUA, you get partial presence, no guarantees.
- Subscribers SHOULD accept only one NOTIFY
- Burden is on the subscriber to implement merging if it wants.
- Won't generally be needed based on domain requirements and frequently won't happen because HERFP.
Conclusion: No time for discussion, taken to list.
----------------------------------------
Watcherinfo Open Issues
- Events leading to terminated
* See previous discussion
- State maintenance for pending/waiting
* Possible Dos? Sub is authenticated
* -01 will talk about setting policy for this
- Tradeoff between user experience and state storage
Stucker: isn't this just a policy issue? Why does this belong in watcher info?
Rosenberg: When you have watcher subs you need to keep state for things being watched. The fact that there's a watcher info on t you need a state. Want to specify a caution with regards to potential for attacks. The watcherinfo draft defines a model for presence. We shouldn't have this in sip-events.
Stucker: Are you going to add when to indicate when subscription is active?
Jonathan: Both have an approved. Want these to align between 2 documents - he's only showing error cases where they don't align
Adam: There are 2 other states: Pending and Active. These are whys for the failures.
Jonathan: Should the state machine be in sip-events. Watcher -info defines a model; you could have much more states and a more complex state machine.
- Elements in data format
* Watcherinfo data
- Uri of watcher
- Status of subscription
- Event which triggered notification
- Duration time in last state
- First-subscribed
- Most-recently subscribed
- Added: expiration
- Removed: Notify-address
Chris: let's ditch most-recently subscribed, it's not very useful.
Rosenberg: Okey-dokey.
Rosenberg: The watcherinfo draft defines a model for presence. We shouldn't have this in sip-events.
- Status in winfo/sip events proposal on the list.
Conclusion: No Comments (thus consensus implied)
---------------------------------------
Guidelines for IM Sessions:
* Context:
- IM payloads are moving away from short-text only, towards
* Images
* Video clips
* Mp3 and other audio data
* Etc.
* Large populations of users meeting over shared infrastructure (interconnect of AOL, MSN, etc).
- Sessions of Messages:
* SIP message is the medium.
- Transport Background
* In order of concern, reliable transport of serious amounts of data raises concerns of:
- Congetion collapse
* Will congestion of the system invoke protocol actions that increase data sent into the system? (1986 TCP collapse)
- Scope of fate-sharing
* Can desired end-to-end behavior and properties be achieved and maintained through intermediaries?
- Congestion avoidance and shared effects
* When J users share a filled or congested path, and adapt, can they get close to each having 1/Jth of capacity?
Allison Mankin: We have to be that when we do congestion control that TCP adapts it's behavior to the congestion on the link. Want to be sure that there aren't unanticipated effects from the extremely large amount of traffic.
* Guidelines Draft
- Purpose is to distill transport concerns, with some related architectural and security concerns.
- Session model
* When data of IM (or session of IM) is carried within headers seen/modified /operated-on by intermediaries
* If you took the MESSAGE, without the headers, and threw it onto an end-to-end TCP connection, it wouldn't create any of these issues. If you have UDP in the middle, you can run into congestion problems.
* If IM clients stop off at the various intermediaries, they get 1/N*M bandwidth (N intermediaries, M IM clients) instead of 1/M, which is a significant penalty. It's because of the TCP queuing system.
Rosenberg: This could happen for a lot of reasons.
Allison: We don't want congestion collapse, but there are some other interesting things going on.
Rosenberg: If we use TCP then this isn't our problem.
Allison: No, the answer is that if you use TCP, don't get greedy with the number of intermediaries.
Christian: There is a fundamental problem here, and it's with TCP.
Allison: I think we still have some value to look into the transport dynamic, and moderate the use of intermediaries. Working on another paper to fully research this. This scenario is a worst case.
- Multi-Intermediary protocols
* Diameter/Apex/Opes/SIP-SIMPLE
- Guidelines for Sessions
* Signaling MUST be able to negotiate a common underlying transport
* MUST not use UDP because of congestion control issues.
* Session/transport solution SHOULD support (MUST?) specifying a single transport protocol for entire session path.
* MUST not use multiple parallel reliable transport connections.
David Oran: Why be so harsh, what's wrong with using UDP in a congestion safe way?
Jon (summary): What we're talking about is that this is the session model, not setting up the session.
Allison: Yes, this is a problem with long streams of data.
- Guidelines for Sessions
* Does design lead to a well-formed session protocol?
- Does the design carry the right data over aggregated transport, session membership, data sequencing, identification and so on?
- Is it designed right for the security goals?
- Draft-iab-opes-00.txt an RFC-t-be from IAB.
- Model for some more architectural guidelines:
* SHOULD not interpose without consent, by at least one of the parties
* MUST support mechanism for discovery of intermediaries
* MUST disclose (either in signaling phase or session) the intermediaries
* More... need to discuss in email.
Rosenberg: The intermediaries are not there to modify the content. It's just there to deal with NATs, etc. Such as in SIP.
Allison: There is an area where the consent issue may be a bit gray.
It's not a perfect match.
Jon: I think we're trying to speak as to what the direction should be, not where intermediaries should be deployed. If the client is informed about what is going on, then it can take action.
Henning: I would hesitate to draw too close a parallel on that, because there are properties in there that make the predictability issue a bit harder. There are issues with discovery and finding that we've had for some time. The other thing is that content modification (via headers, etc) doesn't necessarily match with the consent model in OPES. As long as these are transport entities that don't do much, then you can't extrapolate for OPES.
Rosenberg: Why is this not such a problem for email?
Allison: We're going to have to wrap up, we're running out of time.
* Next?
- End goal is for SIMPLE WG to internalize and feel ownership of the guidelines
- Document should stay individual or be in the set of WG documents?
Jon: we did make a good try at generalizing these issues.
Wcom: I believe that the draft is bloated and it confuses signaling and transport, so let's get rid of it.
Jon: That's unfair, we're responding to what this WG has already gotten itself into.
IMPP WG chair: I don't think that this belongs in either working group.
-------------------------
IMTP Proposal:
* Motivations
- Requirements for IM transport
* Congest
* Reliable
* Arbitrary sizes
* Framing
* Per-im content typing
* E2e privacy, integrity, authenticity
* Works through nat
* Rapid delivery
* Lightweight
* Parser reuse
* Compressible
* Support for different content types
* Muxing
* Logging
- The hard configuration (PC in enterprise 1 going through a ent 1 proxy to internet, over to proxy in enterprise 2 to a PC in enterprise 2).
* How about SIP?
- Pros:
* Parser reuse
* Proxies as intermediaries
* NAT traversal easy
* Logging, framing, sequencing all done
- Cons:
* SIP has features that would get in the way
- Record-routing
- Redirection
- Forking
* Messages might go over UDP
* Performance of Proxy as pure forwarding intermediary is poor.
* Idea: Sip Subset
- IMTP proper subset of SIP
* Remove unneeded features
- Forking, redirection, recursion, record-routing and route
* Introduce restrictions
- Only TCP
* Change protocol field to IMTP/1.0 from SIP/2.0
- Most proxies won't route
- BUT, one-liner to fix that
- Want this to be explicit about what protocol is running
- Proxy with proper configuration can route IMTP
* No forking, no record-routing, no redirect, TCP only
* Can use REGISTER to set up IMTP bindings
Allison: How hard would it be to put in error checking so that if there were an inappropriate header were present it could be dealt with.
Rosenberg: It is a minimal SIP request
Mic: How do we specify IMTP? Where will this be done, where will discussion be held for this since it's a different transport protocol.
Rosenberg: There will be a separate document for IMTP, and will go into this WG. It is burdensome to tie SIP and IMTP together, so let's not.
Rosenberg: We're working on the end-to-end nature of the protocol to specify a key for the session to create an end-to-end solution. We can use that key into S/MIME so I can encrypt the content of the message path.
Security: working on SDP extensions for key exchange (MIKEY) (2 pass) Could use key as input to S/MIME to encrypt e2e. Whatever solutions we develop for SIP would apply to IMTP.
Andrew: What is our reaction? It's not obvious that there's not good engineering necessarily here, but this is what we need to do to get things done.
Henry: What is the problem we're trying to solve? We have fast servers, we have bandwidth, so why is this a problem.
Jonathan: Want a session model for SIP.
Cullen: Can deal with IMTP being a profile in SIP. Can't deal with divergences between the 2. Should keep synced with SIP.
Henning: As long as it's done by reference, then it's not as big of a problem.
Rosenberg: It's not that clear, but it's not by reference.
Dean: Either IMTP reduces to the argument against a session model or argues against using SIP how we're using it now. Believes that if SIP as we've defined it doesn't scale then it's broke, but if it's not broke, then why can't it be used as is for the session MESSAGE problem.
Rosenberg: SIP has the idea of finding the user, and the delivery of the content. The session model for SIP for SIP works by finding the user, then delivering the large data by another piece. SIP is good for the discovery problem and NOT good for the delivery of large data.
Dean: I would argue that if we can't do signaling for call setup, then we can't do messaging, and vice versa. If you want to use a new protocol, why not use BEEP or another protocol?
Rosenberg: Nobody has come forth.
Rohan: I think we should make it so that it absolutely should not go through a proxy.
David Oran: if there is anything to be gained by the MESSAGE method in the IMTP versus in SIP then let's converge them. I don't think it's a big deal with IMTP being renamed. If people think profiling is a reasonable way, then look at MEGACO. Is there anything to be gained from the Message method in paging and the message method in session?
People have said that it's easier.
Dave Oran: Could you share a TCP connection with SIP?
Jonathan: No, but you can share TCP between IMTP.
Rosenberg: I am getting the feeling that it's not a good consensus.
Christian: I like this proposal because it's easy to specify. Do we just have MESSAGE, nothing else, and enable us to do this? It's easy to implement, easy to undertand, etc.
Henning: We have to solve this problem.
Chairs consensus gathering:
* Do we want to pursue this? Hum vote:
- Yes? Delayed hum.
- No? stronger hum.
* Is the session model for messaging important?
- Yes? Hum
- No? small hum.
Rohan: Proposes that unless you get alternative proposals within a reasonable timeframe, that we should just go with this.
Jon: We'll send something out on the list, and if we don't get a response by the end of the holidays, we'll go with IMTP by default.
Chairs consensus gathering:
* If we are going to have a proposal for Sessions of messages, should they adhere to guidelines?
- Yes? Hum
- No? Equal hum
Slides
Agenda
SIMPLE Open Issues
Guidelines for IM Sessions