Notes, SIMPLE WG, IETF 55 1530-1730 Reported by Dean Willis Blue sheets: circulated with some discussion of algorithm, one from the back right and one from the left front. Agenda discussion: No issues raised. Status discussion: Chairs ------------------------- Message has an RFC number. Presence event package has passed WGLC and is in IESG. Charter requires date adjustment. Open question: Do we need a new charter item for PUBLISH? Suggestion from audience that this be handled most expeditiously. The chair reported a consensus to adopt the PUBLISH requirements into the chartered work of the group. Publish Work: Seann Olson ------------------------- Changes in the -01 model, now 3 pieces of information: class, instance or stream header, facet which indicates target group or set of logic that applies. Publication class defines a type. Open issue, should this be mandatory?. Publication facet defines intended water group. Opwn issue: Is the syntac sufficiently flexible? Should this be standardized? Publication Instance provides source identification. Open issues: Should there be an explicit dialog? Is the proposed syntac adequate? Several general open issues raised in slides. Proposal: We should move to an explicit dialog model. We don't do this in REGISTER for historical reasons, and this has caused a mess. It is nice to have an identifier that is persistent across transactions. There are also requirements for name persistence that extend well beyond a dialog, and this is a seperable problem that the authors propose to move to a seperate draft. Question: Why are things like the publication class seperate headers instead of body elements? Short answer is that this requires MIME/MULTIPART automatically. Question: If we solve the greater naming problem, do we still need a dialog? Consensus: yes. Comment that stuff in headers is metadata, understandable by a compositor even when the body isn't. Publish work: Aki Niemi ------------------------ Proposes a general framework based on the Olson work. Provides new "Allow" header functionality for publication operations. Open questions on payload format. Open questions: abandon, integrate with olson, complete in seperate track? Discussion: Publication is really an inherent part of the 3265 events package, it's just getting done later. There seem to be no real conflicts between header use in this work and in 3265. PUBLISH will want to say that future event packages should include details of publication. Further discussion: There may be more semantic analysis of what we mean by "allow/supported" headers here. Poll: Should requirements document for PUBLISH be a working group effort? Proposal that we do requirements here and draft up a solution for handoff to SIP. 3GPP Messaging Requirements Draft: Aki Niemi -------------------------------------------- Includes data manipulation and privacy requirements that go beyond current SIMPLE work. Data manipulation has much in common with conference work in SIPPING and author proposes moving this work there. There are open issues on addressing and message class based diversion, and on charging and security. Author assumes that charging and security fall into the regular work. Question: What do you mean by message class? Answer: We're not sure. It means something like "advertisement" or "personal" or something like that. Question: Is this in e-mail. 3GPP Presence Requirements: Kristian Kizs ----------------------------------------- Require standardized publication mechanism, publishing from multiple PUAs, feedback on publishing and composition, and efficient pu blishing of large multimedia content including partial publication. Several issues with filtering and efficiency described in slides. Question: Process Can this be an informational seperate draft, or should this be in the main requirments body deferred to later discussion. Question on efficieny issue: In some off-list discussions in came up that much of the large-media stuff can be addressed with content indirection. Further requirements on presence document, authorization, and presencelist given in slides. Comment on work process: There really aren't any other requirements documents to integrate this work into. Do we need one? Can we take the requirements out of here and merge them into other work that is going to include them? Chairs deferred this discussion to the list, along with a request for people to lead on various task points. SIMPLE PIDF Extensions: Paul Kyzivat ------------------------------------ Purpose is to represent SIP-specific features in presence doucments. Work spans both the kyzivat (rqmts) and lonnfors (response to rqmts) prescaps documents. Work isw based on callerprefs. Proposes a set of requiremnts discussed in slides. Open question on work process: Enhance these drafts, or seperate into other extensions. Discussion: The discussion of capability registration is similar to other work in ENUM and elsewhere. The whole idea about pushing capability awareness to an endpoint is to allow the endpoint to make an informed decision about whether to attempt communications. Point: This doesn't replace registration. This is on the "other side" of the AOR -- what capabilities does the AOR, not the Contact, support? Generally this is some sort of union of the contact capabilities. Ample discussion followed. Proposal from chair: We go ahead an adopt this is a starting point for the charter item of PIDF extension, emphasizing status appropriate for instant messaging. question: Which of the two referenced drafts are you talking about? Chair response: both: you authors coordinate and go forward. Further discussion deferred to list. Event List Template Open Issues: Adam Roach ------------------------------------------- Issue: mixed vs parallel multiparts? Issue: Metadata, using MIME preamble vs body-part headers. Would a seperate body part be more useful? Do we aggregate meta-data? Discussion: Option 2 (slides) preferred for nesting models by several speakers. Issue: Uniform depth. As defined, subscriptions may require uniform depths in their heirarchy. Does this justify further work? Discussion: This requirements seems to be a headache. If we ever need to include a list from another domain it causes some challenges. This may not happen due to the implicit requirement of understanding an event to subscribe to it? Comment: Experience from LDAP and WebDAV indicates that we will ahve to deal with recursion eventually, so we might as well solve it now. Data Manipulation Requirements Issues: Jonathan Rosenberg --------------------------------------------------------- Open issues: 1) Security requirements, 2) scope, 3) tuple naming Question: To what degree does this relate to filtering: Answer: Anything that can go in a filter should be subject to polciy. Question: We could possibly define a scripting language for this but anything else seems to be insuffient to express policy. Proposal is to remove the scripting discussion as it is implementation, not requirements. Hopefully we can narrow the requirements sufficiently to have choices for the implementation. SIMPLE List Manipulation Semantics: Markus Isomaki -------------------------------------------------- Premise: We see lots of unordered URI lists in SIMPLE applications. A common manipulation mechanism would be very useful. Rather than defining an implementation, the current work defines the semantics requirements of an implemementation. Open issues: scope (presence,only, generic list and auth policy, or general purpose data manipulation), plan, synch model, deciding how to choose actual protocols. Discussion of scope and unification followed. One of the main discussion themes was semantic nature of data and discussion of access control policy language being done in other SDOs. Further discussion deferred to list. Message Sessions: Ben Campbell ------------------------------ Three drafts in the discussion -- SDP descriptions, CPIM/TCP, and Jabber sessions. Discussion will focus on first two drafts. Open Issue: Supporting Intermediaries. How much do we want to say? Discussion: We should show cases one zero, one, and more than one intermediary. Discussion: There are basically two approaches: back-to-back media relays, and something on a globally unique name end to end using something like preloaded routes. Discussion: This is a big change from what we have been doing with messaging sessions. Should we vote on it or something? Comment: There seems to be general agreement on using SDP style negotaition. Issue: Should these two documents be adopted as WG efforts? Discussion: Much of what is in cpim is constant over a session, so we should be able to negotiate these up front, perhaps parameterizing them, and then reuse them. This probably requires a CPIM extension registry. Issue: Do we want RFC 1893 1nad 1894 type confirmations? Suggestion that the delivery reports stuff be pulled out and moved to a seperate documemt. No objections raised to suggestion. Issue: Session keys vs S/MIME. Discussion: S/MIME can use a session key using a shared secret in the SDP. Rohan will work with S/MIME group on this and report back. Note that this applies for encrypted but not signed data. Is Mikey appropriate? General consensus seems to be "not at this time". However, there is a lot of convergence in security going on now, so we can probably defer safely. Issue: M-line format. Three alternatives. Discussion: CPIM/TCP is not a valid token in SDP, no slashes allowed. Further work on SDP format is required. Issue: Comedia usage. COMEDIA makes connection sharing difficult by making it difficult to demux shared connections. Current plan is to get COMEDIA fixed in MMUSIC and then import. If it doesn't get fixed, then we'll have to come up with something else. Question: How do people feel about the work of the design team? Poll: adopr draft-campbell-simple-im-sessions as WG effort, approved by hum, no dissent. Poll adopt cpim-sessions draft as WG effort, approved by hum with several dissenters. Discussion on Jabber-sessions draft: Question: Do we deal with new transports my extending SDP name space, or is there a way to do it using the MIME registry? Suggestion that this should be followed up in the SDP draft.