Last Modified: 2004-09-29
Done | Submission of event package for presence to IESG for publication as Proposed Standard | |
Done | Submission of watcher information drafts to IESG for publication as Proposed Standards | |
Done | Submission of proposed event list mechanism to the SIP working group | |
Done | Submission of requirements for event publishing to the IESG for publication as Proposed Standard | |
Done | Submission of proposed mechanism for event publishing to the SIP working group | |
May 04 | Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard | |
May 04 | Submission of base XCAP draft to IESG for publication as Proposed Standard | |
May 04 | Submission of XCAP event package to IESG for for publication as Proposed Standard | |
May 04 | Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard | |
May 04 | Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard | |
Jun 04 | Submission of XCAP usage for manipulation of presence document content | |
Jun 04 | Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard | |
Jul 04 | Submission of Filtering mechanisms to IESG for publication as a Proposed Standard | |
Jul 04 | Submission of CPIM mapping draft to IESG for publication as Informational | |
Jul 04 | Submission of instant messaging session draft to IESG for publication as a Proposed Standard | |
Jul 04 | Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards | |
Aug 04 | Submission of advanced messaging requirements draft to IESG for publication as Informational | |
Sep 04 | Submission of proposed mechnisms meeting the advanced messaging requirements to the IESG or appropriate working group | |
Sep 04 | Submission of Presence/IM System Architecture draft to IESG for publication as Informational |
RFC | Status | Title |
---|---|---|
RFC3856 | Standard | A Presence Event Package for the Session Initiation Protocol (SIP) |
RFC3857 | Standard | A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) |
RFC3858 | Standard | An Extensible Markup Language (XML) Based Format for Watcher Information |
Minutes - IETF61 - SIMPLE WG meeting - Washington, D.C.
(SIP for Instant Messaging and Presence Leveraging Extensions) Summary: MSRP: Several changes were made in response to Sam Hartman's security review. The group is comfortable with those changes. The number of open issues is rapidly decreasing - we expect these drafts to be last-called after thier next revision. The chairs will obtain appropriate review of the drafts use of SDP. Presence Rules: The group extensively discussed what it means to allow rules based on anonymous or unauthenticated identities. No specific decisions were made during this discussion. Partial PIDF: The group noted the similarity between the differencing mechanisms in this draft and the mechanisms in XCAP. There was consensus to work towards a common mechanism. Partial publish/notify: Draft will be clarified with guidelines on when to use the partial mechanisms. XCAP: The group rejected a proposal to allow idempotency tests other than GET(PUT(X))==X. Jonathan will make minor revision to the core draft which will then be ready to submit for publication. Presence Data Model: The group reached consensus that the model must provide a way to pass potentially conflicting information through a compositor without losing data. The group concluded that the algorithms for applying composition and selecting policy rules will be different. There was extensive but inconclusive discussion around differentiating services (tuples) based on URI equivalency. Raw notes from each session follow: ----------------------------------------------------------- Notes, SIMPLE First Session, IETF61 Reported by Dean Willis Agenda bashed. Status of various drafts presented on slides. Noted that "is composing" is in RFCED queue, not IESG queue. Topic: MSRP ------------------------------------------------------------ Discussion lead by Ben Campbell Slides presented. Changes since last pub and dependencies reviewed. Changes from security review: Added applicability statement around usage with rendezvous/negotiation protocols. Mapping of "im:" URIs. This needs to be in a separate document. Dicussion ensued as to whether MSRP blocks on this document. The general consensus is that it does not, as MSRP never sees an "im:" URL (this would be a rendezvous dependency). Security review suggested reintegrating core and relay drafts. Consensus seems to be to resist that suggestion. Suggested that the full security story needs to be in one of the two drafts. Previous deaft missed RFC 3682 Application Considerations on usage of CPIM headers. This has been clarified. Open issues: "?" Parameter Syntax: Proposed that this be added to the next rev. Discussion: Cullen has a concern that this may break the security model and will review offline with author to ascertain. Overlapping Chunks: Concluded to recommend that most recently received chunk wins unless the application domain dictates otherwise. No arguments raised against proposal. Report handling: Consensus among authors that current draft is underspecified. Proposed that negative reports be "per chunk" and new incremental values for Report-Success (as well as per-message) be permitted. No argument raised against proposal. Further: Relaible delivery requires positive Report-Success or incremental, Report-Failure allows rapid failure detection (along with normal failure timeouts). This would require requesting both success and failure reports at session setup. No argument against proposal. Further: Proposed that spurious reports be silently dropped. No arguments araised against proposal. Discussion: Does Section 8 (O/A, SDP Ext.) need to be reviewed elsewhere? This includes some a-line attributes and fmt, and that sdp-new requires a more detailed registration process. We may also need to register TCP as a transport. Task: Chairs will work it out with other chairs and ADs. Note: TCP has been registered as part of comedia. Discussion: Have there been any implementations? One report of preliminary implementation experience, on which the developers had "serious heartburn", primarily around the abnf that was supposedly fixed in this release. One other concern was raised around handling the closing -- given the structure, one can't detect flow end strictly by ABNF, and list consensus was to stay with this. Discussion: Is the flow control built into MSRP justifiable? If so, then we need a relay push-back capability to handle buffer-overflows. This interacts with "many-flows onto one-TCP" plexing, and providing reordering of chunks. Argued that reordering is required anyhow, so this is no added complexity. Conclusion is that the current text seems consistent with our understanding of requirements. Discussion: Similar SDP-ish stuff is being described in BFSCP. Should we unify? Concluded that the authors will get together and discuss. Further discussion on implementation: Implementors seem to be deferring deployment until the RFC is published. This view is supported from experience reported in 3GPP about their attempt to use MSRP. Topic: MSRP Relay -------------------------------------------------- Discussion led by Cullen Jennings Slides Presented Noted that we need one example in text. Other than that, there have been no comments on-list. Poll: Who is planning to implement MSRP base? (Many, app. 40). Who is planning to implement MSRP relay (much smaller, app. 9). Poll: Who plans to read and comment during last call (very many, 1/3 of room). Topc: Presence Rules --------------------------------------------------- Discussion led by Jonathan Rosenberg Slides presented. Slides review changes from previous version. Discussion of anoymous: Seems to be a desire to differentiate an "unknown user" from a "user authenticated to the network who prefers not to disclose". Is a non-authenticated "From" identity not the same as anonymous? How does this relate to Caller IDs "Anonymous" vs "Unavailable"? Is there a need to present anything relative to the strength of authentication used? Proposed: no plan to add an "authenticated" condition. Unauthenticated identities will be considered comparable to "unknown". Local policy will determine whether any specific authentication technique counts as "authenticated", and techniques below this threshold would be counted as "unknown". Proposed that we may need a way to match "any" identity in a rule. More discussion. New proposal: Delete special treatment "for authenticated but anonymous" and consider all non-revealing identities "unknown". More discussion. Point: Unauthenticated should NEVER receive more information than "authenticated but anonymous". Editor: Why does nobody seem to understand that this is a two-axis system? Axis 1 is "Authenticated vs. Unauthenticated", and axis 2 is "Presenting vs Not Presenting Identity", and that decisions need to be made for at least three of the four resulting tuples? No conclusion noted. Changes since last rev reviewed. Several issues drew brief discussion with some suggestions of discussing offline. Discsussion returned to identity, the uncertain, and the unknown. The result was unclear. ----------------------------------------------------------------------- (Note that we were fortunate enough to have two notetakers for the second session. Both sets of notes appear here) ----------------------------------------------------------------------- Notes, SIMPLE session two, IETF 61 Reported by Ben Campbell ------------------Partial PIDF format 02 (Jari Urpalainen) --"patch" model for pidf docs. add, remove, replace, but no creation. failure falls back to unchanged pidf doc. question: similar to xcap operations--how close is the relationship? answer: very close--same operations that any xml database uses. issue: this is a compression scheme on xml docs, based on diff. We should have one way for all xml docs, not one for each. similar to xcap Further discussion about competing with xcap, and which is more simple and/or compact. Issue: Is this just xcap with different attribute names? Jonathan agrees to look at possible improvements to xcap. Chair: Both this and xcap took divergent evolutionary paths to a similar place--no competition intended. Need to talk to other groups working on xml diff formats. --------------Partial Presence (Aki) *-partial-publish-01 *-partial-notify-03 Radical simplification No longer tuple specific. Issues: What if updated version is garbage? Issue: Do we need guidlines to avoid sending partial pidf that is bigger than whole doc. Don't want to do a large number of small changes. Resolution: We think it is already addressed in draft. (Maybe just notification, but needs to be in publish.) ---------------------------XCAP Needed diffs (Jonathan) Issue: xcap equates get(put(x))==x as idempotency. This is sufficient but not necessary. ( if-match requests are all idempotent) Options: Clarify, but keep normative text; allow other idempotent ops. Proposal:Keep normative text. discussion: does get(put(x))==x also check for concurrent changes? Resolution: accept proposal. Issue: xcap list usage talks about unioning liest elements. But operation is more complex--ns prefix can get lost. (see slide for accuracy) Proposal: when <service> element copied into global doc, add a namespace prefix def for all in-scope ns. If default differes from global def, add a new default. Resolution: accept proposal. chair: draft already last called, need to post changes on list. ----------------------------Presence Data Model Open Issues (Jonathan) Topic: One element vs many. Currently only one person element. Only one definition for any one device or service. question: do we allow multiples? Represents unresolvable conflicting info at compositor. Jonathan and Henning present arguments for each side. Comment: Need ability to be lossless. Comment: Both models may be needed. Comment: No _practical_ one best composition policy. Comment: Need something deterministic to publisher and watcher. Comment: Even an endpoint can publish conflicting information. Comment: Can we have a way to show a "preferred" view of data for dumb consumers, but also show raw or conflicting data for smart consumers? This requires some form of metadata. comment: want to do something today that allows complex solutions in the future, but not necessarily solve all the hard problems now. Resolution: Need the ability to avoid loss and express conflicting data. This will come with some complexities. Will not try to specify all complexity up front, but want to specify some method of specifying a "preferred" instance out of a conflicting set. Topic: Spheres- for variables that serve as rule selectors (e.g. sphere) into privacy policy, need to determine which is used. Composition output and rule selection are logically distinct. Proposal: Allow separate algorithms for rule selection and composition. Selection algorithm could be local policy, or a standardized algorithm. comment: composition could include conflicting spheres. Comment: we need to discuss atomicity of conflicting info. comment: determining sphere priority is policy decision. comment: May need to select included in composed document. Resolution: 1) Composition and selection algorithms are separate. 2) Selection algorithm is application defined for now, but we may need to define a default in the future. Topic: Multiple services with same URI Do we need different identifier, but with same contact ID. What if pua publishes multiple serices with Contact containing AoR? How do you identify conflicting services vs just different services? How about different services at same device with same URI? Example of one softphone doing voice and IM, currently available for IM but not voice. Discussion about whether this is a capabilities problem or something else. We appear to have very different views of what service means, before we can determine encoding. Call attention to henning point: Differentiating tuples based on URI equiv. Do compositors group things into multiples based on URIs. But can compositors cannot canonically compare all URIs. Attempt to call question: 1) What is interpretation of two tuples with same contact URI 2) Should we force a composer to remove and compose multiple tuples with the same URI if it can tell? Resolution: None--take it to the list. ----------------------------------------------------------------------- (Note that we were fortunate enough to have two notetakers for the second session. Both sets of notes appear here) ----------------------------------------------------------------------- Notes, SIMPLE Second Session, IETF 61 Reported by Dean Willis Topic: PIDF Partials ---------------------------------------------------- Discussion led by by Jari Urpalainen Slides presented Comment: There would be a benefit to having some sort of XML compression and partial scheme that would work across applications. Discussion followed on this approach vs xcap diff. Author maintains this approach is shorter and should replace xcap diff. Suggested that there should be comparisons made with real messages. Comment: It appears that the net effect is that we have different XML element names. The previous proposal worked on the element level, whereas this approach is doing more of a syntactic patch. Consensus: We should settle on one technique -- this or XCAP diff, or whatever. Noted that XCAP diff is already a WG document, so we should study this approach and see what, if any, makes it better, then add that to xcap diff. Chair commentary: This is the result of convergent evolution, and we should take this to the list for convergence. We do still have a need for partial notification. We should also check with people outside SIMPLE who are doing XML diffs. Topic: Partial Presence ------------------------------------------------------ Discussion led by Aki Niemi Slides presented. Goal: A small change in presence should produce a small NOTIFY. Noted that this technique should work for any event package using XML bodies. Observed that sometimes, for a very small document, a partial update might be larger than a full update due to the extra syntax. It was discussed as to whether the draft has adequate guidance on "when" to use the partial format. Topic: XCAP Needed Diffs ------------------------------------------------------- Discussion led by Jonathan Rosenberg Slides presented. Issue: Noted that draft needs to clarify usage of term "idempotency". Discussion of this term and usage followed. Issue: Namespace prefix definitions. Fix proposed in slides. Discussion: Could this lead to a collision? Ans. No, the prefix definition is at the service element itself. Conclusion: Author will submit a revised draft. Presence Data Model Open Issues -------------------------------------------------------- Discussion led by Jonathan Rosenberg and Henning Schulzrinne Slides presented. Issue: One element vs. many. Current system does not allow conflicting data. It has been proposed tha twe allow multiple service elements, representing conflicting input to the compositor, allowing the watcher to decide. Proposal: Stay with existing system (argued by JDR). This generates issues for automata as consumers of services. This may also lead to multiple ways of interpreting conflicting data vs. simultaneous capabilities, and could be problemactic. This also requires adding a tuple/element identifier, and may need lots of additional metadata to make the interpretation feasible. Alternate approach would be to add a "<conflict>" wrapper later. Proposal: Add support for many elements (Argued by HGS). Most existing presence systems have only once source of presence data. They don't need to do multiple elements. However, we are now building multisource systems, and need multiple elements to meet additional requirements listed in slides. Noted that one could add a "<view>" or "<conflict>" wrapper now, to accomplish something similar, but that if it is added "in the future", we will have a major backward compatibility problem. Disussion follows . . . Observed that conflicting data will occur -- the Question is how to deal with this. Is there really a correct composition of this data, or is there a consumer decision that is needed? We probably have a need to support delivery of both "vest guess" composition AND full data to consumers. Observed that we may not know how to do the "best" composition in all cases, and therefore probably need to be able to expose uncertainty to the watchers. Observed that it may be important that the publisher understand what the compositor is going to do with its data. This may lead to a need for source-expressable composition preferences, which is hopefully a "future" topic. Proposed that we need to support both models. Proposed that HGS' model would benefit watcher-specific composition. Noted by chair: This means that an "original source" could publish conflicting information. Proposed that the presence document should be able to indicate the "preferred" view among conflicting views, and that this would be usable by "dumb" clients. Also noted that "outgoing" policy might dictate which view is shown to any given watcher. Proposed that there is no "one true answer" for composition. Proposed that a timestamp is not enough to indicate the "preferred" element out of a compositor. Chair summary: Not acceptable for us to produce a lossy model. We want the ability to pass through additional information. We understand that this increases complexity. We will not explain everything, but will provide a hint as to to which one of the conflicting elements is recommended. Issue: Sphere If we have multiple elements, we may have conflicting sphere information. This breaks the current model of using the default composition policy to select which authorization policy applies. Proposal: Allow separate algorithm (not same as default composition policy) for determination of which conflicting variable is used for authorization policy. Much discussion followed. Proposed that perhaps authorization policy should be driven by the view that would be seen by the presentity as a watcher. Issue: Mutiple Services with Same URI Much discussion followed. Noted that there are deployments that don't support GRUU and that some are hestitant to make the solution GRUU dependent. Noted that "Open" and "Closed" at a top-level are inadequate as soon as there are multiple capabilities per device. Discussion devolved into an apparent divide between model views. Chair point: We keep talking about differentiating tuples based on URI equivalency, and whether compositors group according to these same comparisons. This necessitates that compositors be able to ascertain the equivalency of two URIs, which might be difficult. We appear to have no consensus on this at thsi time. Summary: This is going to make a long list discussion, and we may not have even stated the problem clearly. |