XCAP Needed Diffs Jonathan Rosenberg Cisco Systems.
-
Upload
marlene-gallagher -
Category
Documents
-
view
227 -
download
3
Transcript of XCAP Needed Diffs Jonathan Rosenberg Cisco Systems.
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:[email protected]"> <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”