XCAP Needed Diffs

1. XCAP Needed Diffs Jonathan Rosenberg Cisco Systems

2. Idempotency • XCAP equates GET(PUT(X))=X with idempotency • The condition is sufficient but not necessary • Example: If-Match: <foo> requests are all idempotent • Options • Clarify this, but you still need to verify GET(PUT(X))=X  preferred • Allow other idempotent operations currently disallowed

3. Namespace Prefixes in XCAP List • XCAP List usage talks about “unioning” list elements from each user’s document into the global index • However, operation is more complex • List elements may use namespace prefixes defined outside of list element • Unioned document would have undefined prefixes

4. Example Problem <?xml version="1.0" encoding="UTF-8"?> <rls-services xmlns:ext=“urn:extension”> <service uri="sip:mybuddies@example.com"> <resource-list>http://blah-blah</resource-list> <packages> <package>presence</package> </packages> <ext:newthing>new-value</ext:newthing> </service> </rls-services>

5. Proposed Fix • When <service> element is copied into global document • Add a namespace prefix definition for all in-scope namespaces at <service> • If default namespace differs from global <rls-services> definition, add a new default namespace definition • OK? • Should I submit a rev, or incorporate along with IESG comments?

6. Presence Data ModelOpen Issues Jonathan Rosenberg Cisco Systems

7. One Element vs. Many • Ability to provide conflicting data does not exist in todays systems • How to render and use? • Multiple elements are good fodder for varying interpretations and interop problems • Simcaps vs. conflict • Compositor in best position to resolve conflicts close to presentity • Requires adding person identifier

8. One Element vs. Many • Resolving conflicts at watcher requires meta-data • Source • Timestamps • Should solve problem holistically • In the model of a presentity, multiple conflicting data is not a first class citizen • Conflicts complicate things like <sphere>

9. Define a <conflict> element that wraps multiple values of anything else Does not require compositor to understand semantics Although better if it does Would allow two different backwards compatibility modes Pick one value No values How to add it later <conflict> <value id=“1”> <source>calendar</source> <place-type>train</place-type> </value> <value id=“2”> <source>phone</source> <place-type>school</place-type> </valid>

10. Each would be a different service (different unique ID) but same contact URI Purpose Differing capability sets in same UA instance Conflicts How to select one? Caller prefs Use GRUU What if PUA publish services with <contact> containing AOR? Compositor recognizes this as different than <contact> containing GRUU or local address Does not treat as override Basically replaces <contact> value with GRUU Multiple Services with same URI

11. Multiple Services with Same URI • Handling of non-SIP URI • No GRUU equivalent • Can occur in HTTP with capabilities • Real concern? • Equality comparisons • Require URI scheme awareness? • Discovery

12. Device Identifiers • Current draft posits a single device identifier • Recommends OS generation • Henning proposes multiple device identifiers • Hybrid devices like WiFi/Cellular with network-specific identifiers • Utility depends on world view • If applications public device information – not useful • If device publishes about itself – useful • Complicates overriding • If some device IDs match, what to do?

13. Overrides • Want to make sure a PUA can override another publication • Proposal • Default composition policy at SHOULD • Most recent service/device with the same URI wins • For person, combine each element, most recent one wins • Override service: publish with service URI • Override device: publish with device URI • Person: publish new elements

14. Overrides • Key point: avoid override “command” in presence data itself • Presence document stands alone outside of the system • Predictable overriding by default composition policy

15. Tel URI Meaning? • Tel URI can be viewed as a name (basically a URN) that can resolve to anything via ENUM • Need not be a resource in the PSTN • If it’s a name, is it allowed as a contact in service tuple? • No • How can you define status or characteristics if it can point to any number of disparate services? • Why have another layer of indirection? • Less is more • Yes • We already have indirection and multiple services behind SIP • Why not?

16. Options • Disallow tel URI • Allow tel URI with enum dip indicator • Allow any tel URI

17. Service Identification • Current model defines a service by • URI scheme • Characteristics of the service • Continuing concerns over whether this is sufficient • I-D proposes a UDDI-based classification • Discussion

18. Seperate namespaces for children of person, tuple, device or the same? Separate Make it clear for which type of element an extension applies Same Reduce size of documents Eliminate case where two elements of same name in different namespaces have different meaning Help cases where same element is in multiple places Class, user-input Namespaces

19. Timestamp • Timestamp in person and device – needed? • Sure

20. Post-Privacy Composition • Composition policy after privacy filtering cannot introduce additional information • Currently, it can • Resolutions • Composition policy never introduces new information • Limit to merging, splitting and conflict resolution • “Lying” happens elsewhere • There is yet another policy in play here

21. Groups • Do we want to support groups and not just a “legal person” • NO • Need better wording to describe legal person concept

22. Per-Watcher Composition • If “lying” is in scope, we definitely need per-watcher composition • Even if not, we probably need it • Still a part of “who sees what”