XCAP Needed Diffs Jonathan Rosenberg Cisco Systems

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

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

Example Problem presence new-value

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

Presence Data Model Open Issues Jonathan Rosenberg Cisco Systems

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

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

How to add it later Define a 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 calendar train phone school

Multiple Services with same URI 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 containing AOR? –Compositor recognizes this as different than containing GRUU or local address –Does not treat as override –Basically replaces value with GRUU

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

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?

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

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

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?

Options Disallow tel URI Allow tel URI with enum dip indicator Allow any tel URI

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

Namespaces 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

Timestamp Timestamp in person and device – needed? –Sure

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

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

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”