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 ltfoogt 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 users 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
lt?xml version"1.0" encoding"UTF-8"?gt ltrls-servic
es xmlnsexturnextensiongt ltservice
uri"sipmybuddies_at_example.com"gt
ltresource-listgthttp//blah-blahlt/resource-listgt
ltpackagesgt ltpackagegtpresencelt/packagegt
lt/packagesgt ltextnewthinggtnew-valuelt/extnewthin
ggt lt/servicegt lt/rls-servicesgt
5
Proposed Fix

• When ltservicegt element is copied into global
  document
• Add a namespace prefix definition for all
  in-scope namespaces at ltservicegt
• If default namespace differs from global
  ltrls-servicesgt 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 ltspheregt

9
How to add it later

• Define a ltconflictgt 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

ltconflictgt ltvalue id1gt
ltsourcegtcalendarlt/sourcegt
ltplace-typegttrainlt/place-typegt lt/valuegt
ltvalue id2gt ltsourcegtphonelt/sourcegt
ltplace-typegtschoollt/place-typegt lt/validgt
10
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 ltcontactgt
  containing AOR?
• Compositor recognizes this as different than
  ltcontactgt containing GRUU or local address
• Does not treat as override
• Basically replaces ltcontactgt value with GRUU

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

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