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: <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

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

<?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>

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?

Presence Data ModelOpen 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 <sphere>

How to add it later

• 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

<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>

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 <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

• 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”