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 53rd IETF Salon C Mar-20-2002 15:30
Summary:
* The presence and watcher-info drafts are ready for nits review.
Nits review will occur by Apr 5 and will proceed to WGLC.
* CPIM mapping effort is on track for June milestone
* Message session
- Jonathan will provide a proposal for message sessions using normal SIP instead of IMTP, using loose routing to solvev our earlier transport issues
- Analysis of this proposal and IMXP for satisfying transport constraints and CPIM conformity will be provided within 4 weeks (by Apr-22-2002).
* There is general agreement to work on providing solutions for the gaps identified in the simple-components draft. Some of the work would be done in SIMPLE, some in SIP/SIPPING, and some in a few other fora. The work to be done in SIMPLE will be identified and a proposed charter reflecting it will be submitted shortly.
Detailed Minutes (provided by James Undery)
Agenda Bash
+ No issues
Current deliverables
Apr 02 Presence to be submitted
Apr 02 watcher info to IESG
May 02 CPIM mapping to IESG
Jun 02 IM sessions to draft
SIMPLE issues - Jonathan Rosenberg
==================================
Jonathan presented the latest changes and upcoming work for a number of the drafts he is authoring.
Presence
- Alignment with new SIP and sip-events upcoming RFCs
- Removal of 3/4 of examples, removal of example PIDF content from remaining examples
- Additional security, usage of SMIME and sips
- Recommended PUA implement this package, so network can subscribe
- Handle generally applicable issues such as IANA considerations and split references into normative and non-normative categories.
winfo-format
- First-Subscribed will now indicate when the current state machine was first created rather than the first subscription ever
- Removed notify address
- Added expiration params
- Removed most recent subscribed
- id and version attributes will be added after the blackout
Open issue: duration meaningless in fetch operation; Jonathan said to ignore it, speakers from the floor agreed.
winfo-package
- Forking issue need to get subscriptions on all machines handling subscriptions. Two methods were discussed forking or use existing dialog.
Which method to use depends on whether you are the presentity or not. i.e. A pure watcher should use an existing dialog.
- IANA considerations
- State agent text will be rewritten
The proposed schedule for progressing these items was
Arrange nits reviews
Updated drafts by Apr 5 for WGLC
Submit to IESG
CPIM mapping draft open issues - Ben Campbell
=============================================
Ben commented there has been no discussion of this draft on lists. Ben then ran through his list of open issues.
- How the URI is handled at the CPIM gateway. Two methods have been suggested
- Direct scheme substitution
- Leave as a gateway local mapping
- Ben proposed taking the local policy approach. There was no objection.
- Update the draft to take account of changes in the latest SIP spec. e.g. transaction IDs and dialog.
Christian Huitema observed that CPIM was designed to allow SMIME to cover the body, we should check we don't need to change the body at the gateway.
Ben agreed it was reasonable to meet charter deadline of May 02 provided the work didn't have to account for message sessions (due June 02).
Message sessions
================
IMSX - Marshall Rose
--------------------
Marshall ran through a brief presentation of how IMSX and beep would work.
The steps involved were establish a TCP connection, tune BEEP session and then exchange messages. Examples of the SDP involved were given showing privacy being tuned.
At this point Christian noted the problems opening the TCP connection from a SDP negotiation; Rohan Mahy noted this is being worked on by mmusic in the comedia draft.
Marshall explained the tuning process negotiates authentication integrity privacy of the connection and how the initial message can be piggybacked with opening a IMSX channel. The simplicity of the scheme was then covered, i.e. it deals with no addressing, routing,middlebox, message formats or rendering. All these issues are handled by other protocols.
Cullen Jennings questioned if lack of middlebox issues was true. The answer from various people was this was a SIP/SDP/Midcom issue with the session setup.
Ben asked how large is a beep implementation? Marshall estimated that 20 screens would cover the simplest implementation and more feature equated to more code.
Jonathan noted SIP offers a lot of the negotiation feature making large portions of the BEEP/IMSX setup redundant. To which Marshall replied Beep stays out of signaling and noted media protocols might want security negotiation indirectly too.
Christian said attributes should be negotiated in the SDP to remove a level of indirection and that TLS handles negotiation of encryption integrity.
Henning Schulzrinne commented multiple negotiations allows multiple new failures.
Question from the floor is binary data in beep transported as binary or base 64 encoded, the reply was BEEP sends as binary.
A discussion of UDP and TCP transversing middleboxes followed, the consensus was this is a non-issue as it's the same for both proposals.
IMTP - Jonathan Rosenberg
-------------------------
Jonathan ran through the changes to the SIP spec that have greatly aided and simplified this work. The main change to benefit IMTP was loose routing that removed the need to make IMTP a subset of SIP ( by removing UDP, forking and redirection). The requirement now being loose routing can only use TCP hops. Other changes relating to when a proxy can change the Request URI (i.e. only when it owns the domain in the Request URI) means using a FQDN or IP of host ensures no forking or redirection.
Henning asked if this would interference with normal signaling traffic.
Jonathan replied that the element handling IMTP wouldn't necessarily be a signaling entity.
Henning also inquired if it is possible to open multiple TCP connections to handle messages. Jonathan replied yes, however because it's SHOULD to reuse connection this would requires special code for this instance.
A speaker noted that IMTP was routed at application level yet should act like media. Jonathan drew attention to the problems of creating a bespoke protocol and how it'd probably be similar to IMTP anyway.
Christian noted we could stream CPIM over TCP as a minimum, however, we might need a proxy for logging etc. So IMTP is probably minimal for what we want.
Bob Penfield observed using Record-Routes seems overkill. Jonathan responded by saying it was likely that the loose route would be obtained separately routes in the signaling.
The chairs commented we have two concrete proposals neither absolutely flawed, we have the options pick one, pick both or chuck the problem. After a lengthy discussion on the two alternatives it was decided that both options would verify they conform to CPIM sanity checks and report this back within 4 weeks. Once this information was in the WG would be in a better position to pick one or proceed with both.
Andrew Zmolek added that picking one option now doesn't shut the door on the other, SIP can still use it later.
Alison Mankin noted that the proposals should also tidy loose ends as they checked for CPIM conformity.
Page vs Session modes and groups - Jonathan Rosenberg
=====================================================
Jonathan ran through talk showing groups existed in both modes, and characterised with mode was appropriate. Counter examples were discussed, and Jonathan agreed group messaging covered a spectrum of modes and potentially mode transition would be useful.
Open issues were then covered including threading and ordering of group messages, group addressing and maximum message size for page mode (Bis will automatically use TCP for big messages)
Christian noted for security and page mode we want to use SMIME which could be large due to the certificates. Jonathan replied session mode could use a session key rather than certs. Christian also noted this could be a bigger SIP issue.
Jonathan finished with the biggest open issue, how much effort should we put in to adding group mode that is how to use the existing modes one, both or neither. Jonathan recommended for groups mode use session. Henning replied we don't need to make the decision, there are cases for both, we should give advice not make a choice. Dave Oran questioned this asking why would you need group in both, one reason for page mode is latency for the initial message, otherwise use session.
SIMPLE components - Jonathan Rosenberg
======================================
Jonathan gave a presentation of the network components that would be required for a functional "buddy list" application, and suggested we ensure the tools were available to build this.
Jonathan identified a list of what's missing which included; data manipulation, status notification (i.e. is typing notification), message storing, group conferencing, content sharing, threading, publication and glue for above. His proposal was SIMPLE adopt "buddy list" application, adopt a "is typing" solution, adopt development of IM statuses for PIDF, finish message sessions (including threading), adopt data manipulation (i.e. list allow or deny), a presence publication document and an architecture document to put it all together.
Henning commented that we have started group mode and threading. Jonathan noted this is just for SIMPLE, the homeless items are message store (VPIM ?), content vault manipulation (Webdav ?), conferencing floor control (needs a BOF ?) and profiles, user and group discovery (whois++). Lots of people agree this is needed, someone noted this homeless stuff needs to go somewhere. Sean Olsen asked if we can expand the charter to encompass this or pass it out to other WGs. Henning noted another conferencing adhoc had occurred and were going to produce requirements within 3 weeks.
It was agreed to hold an adhoc meeting to continue this discussion
Markus commented this stuff is needed by 3GPP who will be looking at it after release 5. Someone else observed AOL has trademarked buddylist, Jonathan agreed to change the name he used.
A hum on adopting the work and discussing what it means was held with strong consensus for continuing this work.
Keith Drage requested we don't set priorities until input from external groups has had a chance to come in.
Slides
Agenda
SIMPLE Issues
CPIM Mapping of SIMPLE Presence and Instant Messaging