Minutes, SIMPLE, IETF 54Minutes, SIMPLE, IETF54 SIMPLE Working Group, IETF 54 0900-1130 17Jul02 Chairs: Jon Peterson (jon.peterson@neustar.biz) Robert Sparks (rsparks@dynamicsoft.com) Full Notes (taken by Dean Willis) Agenda presented, accepted MESSAGE Update, Ben Campbell MESSAGE method in IETF last call, waiting IESG feedback. There have been several small changes. This draft has added an option for large messages if congestion-safe transport is used. Also clarified Expires header, although new discussion of this topic has occurred on list in the last 24 hours. Use of 0-value Expires as "immediate" request label is an open question vs "Priority". Audience poll favored current usage with 0-value. There has been discussion of a stronger requirement for REGISTER with method-message. Current discussion is to leave it as currently documented. Motion made from floor to leave well enough alone -- barring major issues, just go with the current form. CPIM Mapping, Ben Campbell Recent draft has minor changes to sync with 3261, but has CPIM dependencies. IMPP chair Mark Day reports that CPIM has experienced a resurgence of interest and may be the last deliverable from IMPP, with a due date on the order of "a couple of months". SIMPLE Data Manipluation Requirements, Jonathan Rosenberg Presence List Changes: Terminology change from "buddy list" to "presence list" in latest draft. More data than PIDF needed due to requirement for partial update, including full/partial update flags to allow differential updates. Lists may include lists, so the list server subscribes to list package for each entry rather than the basic presence package, thereby providing nesting. Open Issue #1: Should PL be a Template package? Discussion presented in slides. Open question -- is a new body type required? Current draft proposes a multipart body with a madatory base class and an optional seperate "collection" body with references to other elements. This preserves the original bodies in an unmodified fashion and allows package-indpendent collection servers. Example bodies presented in slides. Comment from floor: this has some similarity to SynchML and may justify examination thereof. Comment from floor: This multi-level approach is interesting, but the given approach has a lot of overhead. Also the proposal doesn't seem to have any way to distinguish multiple elements. 2nd comment adddressed, spec requires that templateable packages specify a URI to reference elements. Application/versioninfo should be an XML document with full referencing. Comment from Patrik: Mixing MIME dividers and XML dividers can be problematic, especially if signatures are used. Response: Reason author likes multipart/mixed rather than pidf is that this appproach preserves signatures and seems to work. Open Issue #2: Too Many Choices Current draft allows PIDF, PLIDF, Multipart Mixed, all of which have assorted issues discussed in slides. The Collection Template approach discussed above seems to allow mixing of these types while clearing all of the noted issues. Open Issue #3: State of Suscriptions The Presence List Server is a "fan-out" server. There's currently no way to know the state of the fanned-out subscriptions on a transitive basis. Proposal is to aggregate this information in listinfo format as proposed in collection template class, then support partial updates. Discussion: What would the event header look like? Proposed alternative: multipart/mixed with message/sip inside. This would reduce maintenance of collection formats. Response is that this would keep all of the overhead of SIP routing information -- cseqs, etc. and would create a great deal of overhead problematic for wireless applications. Open Issue #4: Sharing Of Versions Issues discussed in slides, all cleared by proposed collection model. Open Issue #5: Which Package does PLS use? Several options proposed: 1) presence.collection, fallback to presence, 2) add labels to lists so they can be parsed as lists 3) user has to KNOW that a subscribed list is a list, not an individual, 4) Server OPTION The URI to discover that it is a list, then uses appropriate package, which works as long as role of URI is fixed. 5) disallow recursion. Comments requested: Question: How are 1, 3 ,and 4 not complementary? Ans: Original proposal was "All but 2". This results in notifications that exceed the scope of the subscription, which could be confusing to sort out. Question: How do you identify these? The event header was "buddy list", what now? Ans: It was always a request URI, the only thing that changes is the event name. Question: Could the AOR be a bddy list? Ans: Yes, but not in an overloaded condition where the URI presents both an indivdual and a list. This would seem to be a reasonable interpretation of URI usage. Question: What about multipart recursion? Extended discussion followed . . . discussion deferred to offline. Question: If something has presence but not presence collection, would it be reasonable to serve up presence instead of a prsence collection? Ans: yes. This will be clarified in draft. Audience polled: Is going in the direction of a template class generally reasonable? Answer favorable, none opposed. Data Requirements, Jonathan Rosenberg Presence and IM systems use multiple data elements to drive the applications. We need to manipulate these data items, interact with, change, etc. them. This is disjoint from the subscription and notification mechanism, and includes read and write mechanisms with caching (offline access, and modification) and security requirements (listed in draft). Question: Does this create additional requirements around concurrent offline changes and reconciliation? Ans: Not a requirements issue but an implementation issue. Comment: This topic could use its own working group, we should perhaps not solve it here. Ans: We're just talking about requirements and really expect to reuse an existing solution like SyncML. Comment: Should study data model in ACAP very carefully. Ans: Authors are already working with ACAP author to analyze. Extended discussion on tradeoff of authorization, inheritance, and cacheing issues followed. Open issues include 1) Do enough of the data manipulation type things we do fit under this model to justify further work, 2) Should we generalize or do something specific for presence lists? 3) How do we align with SIP conf work? 4) Should we adopt as a WG item? Comment: This is a large problem space, and includes things like WebDAV, XPath, XML database, and probably becomes at least a New York sized rathole. It probably would be a bad idea to choose to do something limited to the presence list problem. Comment: There's a lot of overlap with W3C and other work, we should collaborate. Comment: This is similar to the UA configuration task, can we combine them? Comment: Is this really a semantic manipulation problem, or a remove text editing problem? Comment: What is start with a pure XML framework, then we can use stuff like XPath and see if it works. Comments: We should at least work on this here, starting from specific topics in charter. Poll: Should this work be adopted as a wokring group item toward existing charter goal? Response favorable, none opposed. The PUBLISH Method, Sean Olson The critical issues here depend on the composition model in the preceeding discussion. The basic model is discussed in the slides. The contentious component of the draft is the "slot" model of presence composition. Open issues include: 1) Should we include CPL problem in scope, Proposal, No. 2) Is "slot" idea right way to go? 3) Do we need to standardize PType tokens? 4) Should PType require IANA registration? 5) Should PState be replaced with Expires header? Comments: This seems to be the micro-version of WebDAV, but scope-limited for just the PL problem. This may argue that the very general "PUBLISH" name is too broad. Also, do we really want to differentiate between hard-state and soft-state data? Ans: Name can be changed. Authors have deliberately restricted to soft-state because this data has direct correlation or "binding" with SIP routing and cannot be well addressed by other mechanisms like WebDAV. Hard-state information does not seem to have this characteristic. This is particularly crucial for third-party manipulation of soft-state information given only a SIP URI as a key to that information. SIMPLE isn't deployable without this and it has to be fixed NOW. The requirement here is scoped explicitly by SIP Events. Comment: Can we identify a reasonable stopping point? The model of having to find a "stopping point" based on a SIP URI seems reasonably common. Proposal: Could we do PUBLISH via a reversed subscribe/notify model? Discussion of this approach not favorable. Question: How does one manage policy of slot composition? Ans: The composition policy of a compositor is locally determined. 3GPP Presence Requirements, Krizstian Kiss Slides summarize requirements. from draft. Discussion of requirememt "Keep all PUAs aware of each other's publishing": Comment that this seems to be contradictory, it would be better to make publishing transparent across devices. Ans: This is because we have "network attributes" that have to work this way. Further discussion deferred. Comment: there are requirements for filtering in a lot of our discussions, we should add to charter. Comment: partial notification is messy. We need to clarify this. For example, CPIM and partial notification are conflicting requirements. Comments on requirment for anonymous subscription: This means the subscriber is anoynmous, not that the subscription is invisible to the prsentity, right? Ans: yes. Comment: If geoloc is part of presence document, how does it get composited? Ans: simply -- just reference the geoloc document. There are lots of authorization issues around WHO can update and/or see geoloc. Discussion: Is it reasonable to accept requirement from 3GPP? Discussion: Rather than having "3GPP requriements" on our charter, shouldn't we simply integrate these requirements into our chartered requiremeents documents? This proposal seems to be generally favorable to the audience. 3GPP Instant Messaging Requirements, Aki Niemi This document is intended as a "heads up" to IETF. The work is at a very early stage in 3GPP. Formal requirements are expected by IETF55. IMSX Protocol Evaluation for Session-Based IM, Mary Barnes Analysis presented. Comment: Although it doesn't currently support threading, BEEP could so so easily. Comment: Although there may be objections to implememnting yet another protocol in a node, SIP does shine at multiprotocol stories and really does work well with a mix of transports and codecs. Comment: The status of IMXP does not seem clear, as there have been apparent strategic shifts by the author (Jabber). Comment: Rohan said something about IMTP and strategic subsets and Fred Baker, but this reporter didn't parse it. Comment: messages are somewhat like media, and somewhat not like media, and we probably don't need a divergence between session and pager model. Comment: We seem to have only one proposal -- use SIP. The idea of defining IMTP as a seperate protocol subset seems pointless. Defining the session model as a stream of MESSAGES bounded by a dialog seems like the right thing to do. Comment: Using SIP without changing the name clearly violates the spirit and letter of our own SIP guidelines and has potential interop problems. Comment: If somebody is going to define a new proposal, they need to do it really soon. We really DO have only one draft under current consideration. Proposal: Let's just move forward with Jonathan's draft, in a non-exclusive sense. Discussion seems to favor this as the baseline default, and we can do additional stuff later if needed. We should immediately discuss on list and conclude whetehr we go forward immediately with SIP or a renamed SIP-subset (IMTP).