Last Modified: 2003-02-26
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, including for example 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.
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.
|JAN 03||Submission of instant messaging session drafts to IESG for publication as Proposed Standards|
|JAN 03||Submission of presence list package set to IESG for publication as Proposed Standards|
|JAN 03||Submission of presence list auth/modify requirements draft to IESG for publication as Informational|
|FEB 03||Submission of requirements and proposed mechanism for event publishing to the SIP working group|
|FEB 03||Submission of CPIM mapping draft to IESG for publication as Informational|
|FEB 03||Submission of advanced messaging requirements draft to IESG for publication as Informational|
|MAR 03||Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard|
|APR 03||Submission of Presence/IM System Architecture draft to IESG for publication as Informational|
Minutes: SIMPLE IETF 56 17Mar03 1530-1730 Reporters: Dean Willis, Pekka Pessi Editor: Robert Sparks Summary: - Announced the impending SIMPLE Interop - Called for volunteers to host a SIMPLE Interim before Vienna - Consensus points * Publish - Handling hard state will be left to local policy - HTTP vs SIP discussion does not belong in requirements document - Meaning of "tuple" is unclear and needs attention * RPIDS - draft (except ) accepted as starting point for charter item * isComposing - strong support to seek bringing this draft into charter * Filtering and partial notification requirements - strong support to seek bringing these drafts into charter ======================================== ====================================== Notes reported by Dean Willis Chaired by Robert Sparks, Jon Peterson 1530 Called to Order, Peterson Topic: Agenda Bash -- no objections Topic: Administrivia. Revised charter pending. Reviewers needed for documents (Rohan volunteered). Interop event needed. Volunteer for hosting by Jasomi at Banf or Calgary, 3rd or 4th week of April. Proposal for interim meeting before Vienna. Topic: Message Sessions, Ben Campbell History reviewed in slides. Message Session Relay Protocol (MSRP) work attempted to resolve dependecy on co-media. Design work decided to abandon co-media. Current draft is similar to cpm-msg-approach but addresses multi-nat scenarios, common firewalls, multiple IM sessions on a transport session. Some co-media issues resolved around bidirectional communications, and relay support. Note that this protocol does not address relay discovery, but relies on knowledge in endpoints. Note that in slides, all requests have hop-by-hop responses except for SEND operation, which is end to end. Open issue: ACK related bug in offer-answer, may address with UPDATE. Do we need a refresh mechanism for BIND? There is also a race condition when tearing down a session (between release and leave). Question re: refreshing the BIND: Could we do one BIND instead of multiples using crypto cookies ? (Send text). Open Issues: Need to fully define msrp URI scheme. Do we needs msrps:? Open Issues: Security. Digest auth on BIND needs to be specified. Question: What do we get out of having digest auth on BIND? Do we need an msrps: scheme? Note that there are three identities here -- the user identity, the server identity, or an alias identity. This authentication is for protecting the "bind" side of the relay. Currently, the "visit" side is not authenticated. Note that the usage of TCP servers behind a firewall is no more secure than running a UDP server behind a firewall. Further conversation to list. Topic: Publication of presence data: Jon Peterson, Sean Olson Requirements document broken off from mechanism document: Jon Peterson Open isue: Hard state requirements. Discussion defines "hard state" as the default condition or absence of freshly published state. Question: Is there a requirement for hard state? Poll: Should this be in scope of requirements? Argument: This is a matter of local policy on the compositor function. So, "hard state" as defined here is just policy. Audience (Henning): I agree that this is a special case of policy. Is the manipulation of policy part of the requirements? Question: Where does discussion of HTTP vs SIP live? Requirements, or implementation? Publication mechanism: Sean Olson Changes since last draft simplified, now very much like "options" request. Added new out-of-sync response code and versioning requirements, met by time-stamp of CPIM-PIDF. PUBLISH is now non-dialog, soft-state, and logically scoped to a tuple. S/MIME is used for privacy and integrity, and compositor must respect end-to-end security requirements from the publisher. Discussion: PUBLISH with an expiration has granularity of the contained document, not individual tuples. This might preclude composite of end-to-end protected tuples. Issues: Need better definition of tuple. Discussion: This is one of the most fundamental things to work on, but we argued against defining it in IMPP. Much discussion on definitions illustrated we don't have one. Issue, do we need Facet header for authorization of tuple watching. Question: Can we say that RPIDS is a better PIDF that people will actually use? Unresolved. Topic: RPIDS, Henning Schulzrinne Motiviation and overview given on slides. In short, a presence information format for publication and notification. Adds device capabilities. Represents groups, with status within the group. Suggestion that group representation be abstracted into a different document. There is also an aspect of list composition functions that is needed. Issue: label tag, which is similar to the pidf id tag but has defined semantics on setting by presentity and applies to publication rather than notification side. In short, there should be no two tuples in the same presence document that have the same label. Issue: elements, no discussion. Issue: what is a tuple. Three models presented: common AOR, generated by capability set, and contacts representing devices (wityh privacy and duration issues). Proposed that we document all three, but where? Comment: This does need to get resolved -- can we get this nailed down by interim? Can we adopt this as a WG effort? Poll: document seems widely-read. Given that, should this document be a wg iterm reflected in charter? Strong consensus indicated. Topic: IsComposing (istyping) state indication (vs idle): Henning Schulzrinne Slightly revised, open issues under discussion, poll to make WG status? This will require deliverable add on charter. Poll to add iscomposing to SIMPLE charter? Strong consensus shown. Comment from future AD: Would like to have discussion of extensibility model. Comment (Bon Wyman): There have been notifications of IPR on istyping. Can we work around this IPR? Comment from AD: Part of the WG's evaluation is around IPR issues, so this discussion is valid, and consideration should be given to the IETF's IPR declarations page Topic: Data Manipulation, Jonathan Rosenberg Point: This is general application data manipulation and is worthy of a broader discussion. ACAP provides a model. Proposal includes algebraicly scoped lists of lists-or-nodes. The ACAP data model seems to be a good fit, bu the protocol itself has issues around persistent connections, lack of intermediary support, underlying security primitives (SASL), and syntax inconsistent with SIP. Discussion ranged around comparison of ACAP attribute model and relationship to XML. Question raised as to "why look at ACAP -- it's old" Comment: Could we use WebDAV? Comment: The configuration work in SIPPING could probably support this. Further discussion deferred to list. Note that this basic piece of functionality is a critical show-stopper for SIMPLE deployments. Topic: SIP List Events, Adam Roach Revised as a full event class rather than as a template. Open issue: filters, several points need review. Author requests review of the XML usage (Sean Olson volunteered). Proposal for downstream forking example received no objections. Needs more eyeballs. Topic: Partial Notification Filtering, Hisham Khartabil Motivation and requirements presented. Proposed solution is XPath expressions, leaving an open issue around triggering ("when", as opposed to "what"). Poll: Is there a need for this sort of thing? Discussion: Watcherinfo and others are using similar functions, so it is probably useful. Discussion: Xpath may not have sufficient expressivity. Poll: Have reqs drafts been read? Yes. Poll to bring reqs drafts onto charter, mostly positive. Topic: Partial Notifications Mikko Lonnfors Defines requirements for partial notifications. Discussion: One requirement is to "not change charging model" -- that's probably out of scope for this WG. Poll: "go forward with this draft": moderately positive, no negatives. ======================================== ======================================= Notes reported by Pekka Pessi Administrativia --------------- * interop * interim meeting before Vienna - call for volunteers/sponsors Message Sessions (Campbell) --------------------------- * draft-campbell-simple-im-sessions-01 * MSRP - attempts to solve problems related with COMEDIA - lot like message sessions discussed in Atlanta - differences: - no comedia - handle intermediaries more explicitly JR: more than NATs, handling intermediaries within different admin domains - supports common fw policies, where parties behind - problems with COMEDIA - no good way to match incoming connection to particular session - NAT breaks COMEDIA usage of source addr and port JR: comedia uses port number as principal multiplexing identifier, that cannot be used with intermediaries - implicit support for two or more relays - MSRP primitives: - BIND: establish session - relay discovery protocol is out of scope - VISIT: associate connection with a session - Host/Visitor: - diagram explaining host/visitor relationship - diagram explaining one relay case: host-relay-visitor case - diagram explaining two relay case: host-relay-relay-host - this is tricky - relays can establish connections between each other based on DNS information from message uris - Open issues: - ACK-related Bug in o/a handling: - refresh mechanism for BIND - race condition when tearing down a session Aki Niemi: BIND only once, use a cookie to make difference between sessions Rohan Mahy: use soft state for BINDing - msrp: URI scheme - SDP encoding assumes that the host and visitor temp URIs have same domain - Additional work needed for security - digest authentication - msprs needed for security? Jon Peterson: what are security properties we need? JR: relay wants to make sure that only a authenticated user may set up binding on it? RS: use TLS to prevent anonymous usage? AN: what is the identity that is being authenticated BC: authentication is only between host and relay Cullen Jennings: do we need to authenticate visitor? JR: provide same level of protection as in COMEDIA, make msrp URIs unguessable to prevent anyone from being a visitor CJ: make sure that no-one can use this to create a generic socket server that can be exported outside firewall - end-to-end security - MIKEY, etc. RS: object very very soon on the mailing list if this draft is not on the right path PUBLISH requirements -------------------- - there is hard state and soft state for the presence * Requirements for hard state (or default state) * Use PUBLISH or something else to set the hard state * Hard state in or out? Aki Niemi: there should be such a concept; when you are out of the coverage you should have somthing to deliver to subscribers Sean Olson: should hard/default state be CLOSED? RJ: the default state is a matter of policy, policy covers hard state Adam Roach: installation of hard state is out-of-scope of PUBLISH HS: this is a special case of policy, there should be mechanisms to upload the default document SO: it is requirement for presence/publish system, it can be done with data manipulation, too JP: should the default presence document contain a CLOSE tuple or may it be empty without any tuples at all? - HTTP v. SIP discussion is out of scope of the requirement doc draft-olson-simple-publish-02 ----------------------------- - updates from -01: - was too complex, removed extra headers - added 494 Out of Sync - because removed headers, added set of requirements for the semantics of the PUBLISH body (that are fulfilled by CPIMP) - versioning handled by the body ( for CPIMP) - no dialog - PUBLISH handles only soft state - PUBLISH is scoped to a tuple => each tuple can be manipulated separately - when end-to-end security (like S/MIME) is used, compositor must respect that HS: we must be very careful with tuple-ids SO: publisher can handle each tuple separately JR: this is extremely PIDF-specific SO: this is only model that makes sense if you want to manipulate tuples separately - Issues: - examples were missing Max-Forwards - definition of tuple is unclear? BC: important issue JP: each tuple is identified by an unique contact address of my PC? AN: (does a tuple contain a) contact address of you? Dean Willis: tuples are attribute-value pairs for presentity? - Do we need Facet header for authorization of tuple watching (ie. "Who sees what?") AN: this is definitely a policy issue RPIDS ----- * richer presence information than basic PIDF - SIP-aware, translatable to CPIM easily * merged with cp-based documents for describing presentity properties * Draft overview - Presence status - Timed status: new thing - e.g., person was in a meeting an hour ago - Device capabilities - Allow presentity to represent groups * Problems: - groups can contain groups - at odds with list presence (but more efficient) - ok, ditch groups for now BC: agree RS: was going to ask pulling groups to a document of its own RJ: current list does not handle the combined status very well, the status of the group is useful and should be kept * Problems: - PIDF has id tuple tag - allows handling of diffent tuples - who owns each id? how to handle it? RJ: "id" is for receivers, something else is needed for composition - use "label" tag on backend side - also use something like css (which has id and class) - each element has two kind of identifiers -> enables policy filtering * Open Issues: - extending - ortogonality: how to combile activities - What is a tuple? - AOR, custom address for each capability set, device address? HS: solicits comments JR: this is most important issue Brian Rosen: have a bar bof => Hum accepting this draft as working group item is-composing ============ * Bob Wyman: there is some IPR issues * Patrik Fältström: WG should take into consideration potential IPR when processing a document, nothing more, nothing less Data Manipulation ================= * manipulate buddy lists * manipulate authorization policy * examples ACAP (RFC2244) * generic mechanism for application-independent access to per-user application configuration data from multiple clients - Presence list with ACAP - Authorization policy with ACAP: requires defining processing logic of authorization entries, no need for scripts - Data model of ACAP is fine, protocol is bad - sasl (ACAP security model) is not compatible with S/MIME etc - no intermediaries allowed HS: has concerns with data model C. Huitema: why unearth this protocol? why not LDAP or SNMP? JR: take things that work, replace things that won't for use RM: use something that has a URI AN: document has two sides, nice datamodel and so-and-so protocol JP: split document? take it to list Presence Lists (Adam Roach) =========================== * take 3: an extension to sip-events - list contents as a multipart - meta info in xml mime body part * open issue: filters? do they apply to top-level list, the nodes, or both? RM: do we need to take this to sipping? JR: we are chartered to do this Presence Filters (Hisham Khartabil) =================================== * eliminate unnecessary and unwanted notifications and contents * solution based on XML style sheets (XPath) JR: triggering stuff is needed (winfo) there is many different stuff going on here filter can be generic, triggering probably package-specific HS: while xpath can do simple arithmetic, semantics of triggering and filtering may be different, xpath may not be enough, CPL-like approach might be better? JP: motivation/requirements draft can be taken in charter Dean Willis: solutions documents might be better in SIP WG Partial Notifications (Mikko Lönnfors) ====================================== * send only the modified parts to watchers BC: charging model? ML: requirements coming from 3GPP JP: more reviewers needed for these drafts