XCAP

1
XCAP

• Jonathan Rosenberg
• dynamicsoft

2
Agenda

• XCAP Base
• XCAP List
• XCAP Event Package
• XCAP Authorization Usage
• Presence Data Model
• XCAP Multiple Inserts

3
XCAP Base

• Almost There!

4
XCAP Base

• ISSUE 5 Multiple Insertions
• Deferred
• ISSUE 6 Select by Text
• No
• ISSUE 7 Unique Steps
• Required
• ISSUE 8 Etag Scopes
• Document
• ISSUE 9a Namespace Discovery
• Through extension usage
• ISSUE 9b Etags useless for insert
• Documented

• ISSUE 1 Schema Awareness
• Only validation
• ISSUE 2 Positional Insertion
• Added
• ISSUE 3 PUT v. POST
• PUT
• Client sets data
• ISSUE 4 Separators

5
Other Changes

• AU specifies uniqueness constraints
• XCAP servers dont do referential integrity
• Resource interdependencies defined
• Removed ltmandatory-nsgt
• Multiple xcap root ok no information carryover

• Added escape coding
• Reworked error report document
• Capabilities application usage
• Changed MIME type names
• Addressed do we need filename issue
• Added guidelines for app usages

6
Issues Raised in WGLC

• DELETE Idempotency
• XPath Namespace Context
• ETag and DELETE
• Caching

7
DELETE Idempotency
  ltfoogt      ltbargt contenta lt/bargt      ltbargt
contentb lt/bargt      ltbargt contentc lt/bargt   
lt/foogt

• DELETE needs to be idempotent
• Wont be for positional deletions
• Similar issue with insertions
• Solution
• URI has to have two properties
• Identifies one resource before delete
• Identifies no resource after
• Inverse of insertion

DELETE foo/bar2
  ltfoogt      ltbargt contenta lt/bargt      ltbargt
contentc lt/bargt    lt/foogt
DELETE foo/bar2
  ltfoogt      ltbargt contenta lt/bargt   lt/foogt
8
XPath Namespace Context

• What is the namespace context used for evaluating
  a step?
• Default namespaces
• Element and attribute matching
• XPath 1.0
• Namespace from evaluation context
• Default is null

• How to handle this case

ltfoogt ltbar xmlnsNS1 xmlnsns1NS1/gt
ltbar xmlnsNS2 xmlnsns2NS2/gt lt/foogt
Select this
foo/ns2bar
9
ETag and DELETE

• Etag is associated with a resource (URI)
• After DELETE, the resource doesnt exist
• Presumably 200 OK doesnt carry Etag
• Thus, you lose track of document after DELETE

• Options
• Document limitation
• Put in Etag anyway
• Empty resources
• Empty Resources
• A resource exists as long as parent exists and
  is not empty
• To delete, you PUT it to empty
• To insert, you modify from empty to content

10
Empty Content

• Pros
• Makes etags useful for all operations
• Cons
• Hack
• May interact with other mechanisms
• Complicates simple cases

• Proposal
• Document limitation

11
Caching

• XCAP says nothing about cache control
• It should
• Proposal
• Not really different than other content
• If you allow caching, it might be stale
• PUTs may be against sub-resources, making
  staleness likely wont be picked up by server
  processing PUT

12
XCAP List

• Lists, lists and more lists

13
XCAP List

• ISSUE 1 Scope of entry-ref
• XCAP Root
• ISSUE 2 URI of ltentrygt attribute or child
• Attribute
• ISSUE 3 name or URI as ltentrygt index
• URI
• Canonicalization defined

• ISSUE 4 Index document
• Added RLS Services document
• Server generates composite document in global
  tree
• Picks off docs in specific place in user tree
• Somewhat obviates need for XCAP directory

14
lt?xml version"1.0" encoding"UTF-8"?gt ltrls-servic
es xmlns"urnietfparamsxmlnsrls-services"
xmlnsrl"urnietfparamsxmlnsresource-lists
xmlnsxsi"http//www.w3.org/2001/XMLSchema-insta
nce"gt ltservice uri"sipmybuddies_at_example.com"gt
ltresource-listgthttp//xcap.example.com/resourc
e-lists/ users/joe/index//
resource-lists/list5b_at_name22l1225d
lt/resource-listgt ltpackagesgt
ltpackagegtpresencelt/packagegt lt/packagesgt
lt/servicegt ltservice uri"sipmarketing_at_example.c
om"gt ltlist name"marketing"gt ltrlentry
uri"sipjoe_at_example.com"/gt ltrlentry
uri"sipsudhir_at_example.com"/gt lt/listgt
ltpackagesgt ltpackagegtpresencelt/packagegt
lt/packagesgt lt/servicegt lt/rls-servicesgt
15
Issues Since WGLC

• Embedded vs. External Resource Lists
• Simpler structure for RLS services doc
• Support for membercode from draft-hiller-uri-lis
  t-index

16
Embedded v. External Lists

• RLS Services doc allows resource lists to be
  specified by value or reference
• Reference has to be within same XCAP root
• Jari asks why both? Why not just by reference?
• Desire to have a self contained buddy list
  document
• Avoid referential integrity ugliness for simple
  cases

17
Simpler Structure

• Jari asks, cant we just define each RLS service
  by its resource list?
• I dont think so
• RLS service uses a lot of provisioned data
• Resource list is just one piece
• Spec also defines allowed packages
• Other things for the future
• Index to authorization policies
• Back end subscription policies
• Keep it extensible

18
Support for Membercode

• Draft-hiller-uri-list-index proposes a small
  payload for specifying subscriptions to list
  subsets
• Requires each list entry to have an integral index

• Currently, resource lists dont have this index
• Cannot be added, schema doesnt support that type
  of extensibility
• Options
• Ignore
• Add attribute extensibility
• Add membercode now

19
Membercode choices

• Ignore
• Not a chartered item
• Feature creep
• Add extensibility
• Allow it later
• Needs to extend the app usage in addition to the
  schema

• Add membercode now
• Con similar to the name attribute we just
  removed!
• Pro will be work to add later
• Proposal
• Add attribute extensibility

20
XCAP Package/Diff

• Change is good

21
XCAP Package

• Major Changes!
• Unified with Config Framework
• Draft-ietf-sipping-config framework
• Event package
• Event header parameters to specify what you want
• Draft-ietf-simple-xcap-package
• XCAP diff format
• Can be used as a MIME type in config package

• Benefits of unification
• Single bootstrapping and data discovery framework
• Allows for bootstrapping to start and stop at
  various layers

22
Bootstrapping points

• Client knows its username, password, but not
  applications
• SUBSCRIBE sipuser_at_domainEvent
  sip-profileprofile-nameapplication
• Client knows username, password, and the specific
  app usage
• SUBSCRIBE sipuser_at_domainEvent
  sip-profileprofile-nameapplication
  app-idresource-lists
• Client knows the specific document
• SUBSCRIBE sipuser_at_domainEvent
  sip-profileprofile-nameapplication
  app-idresource-listsdocumentuser/index

23
XCAP Diff Format
24
Relationship to directory

• Directory allows discovery of documents on
  startup
• Config framework allows discovery of documents on
  startup
• SUBSCRIBE to user_at_domain with Event sip-profile
  and profile-name of app and Accept of xcap-diff

• Returns an xcap-diff document listing all of my
  documents and global documents of relevance
• Same function as directory
• Proposal directory not needed

25
XCAP Auth Usage

• Picking up the Pieces in light of a Data Model

26
Issue A Sphere interpretation

• Problem
• ltspheregt as a condition can be ambiguous
• What tuple are we talking about?
• Previously if ambiguous, condition fails

• Data Model Impact
• ltspheregt is a presentity characteristic
• There is only one per document
• Problem eliminated

27
Issue B Sequencing

• Problem
• Do we do authorization first, then composition,
  or the opposite?
• Do our documents define composition

• Data Model Impact
• Defines a specific data processing sequence
• Separate composition control aka how you land
  at a concrete document from privacy how you
  strip it down
• Problem eliminated

28
Issue C Post Privacy Composition

• Problem
• What happens if document, after privacy, has
  tuples which dont differ much?
• Do we mandate re-combination? Optional? How to do
  it?

• Data Model Impact
• Post-filtering composition is done
• Guided by composition policy (TBD)
• Problem solved

29
Issue D Different Docs to Different Watchers

• Problem
• Can authorization policy allow me to give
  conflicting information to different watchers?
• Previous Answer
• Yes presence doc has inconsistent tuples
• You pick which one to send based on class

• Data Model Impact
• Each service or device can be represented only
  once
• Thus, a document cannot have conflicting data
• The problem is thus relegated entirely to
  composition policy
• Specifies which inputs to include in a document
• Problem solved

30
Issue E Separate subscription from document
processing

• Problem
• Currently, authorization policy jointly specifies
  how to process subscription (accept, block,
  polite block) from how to process data
  (transformations)
• Should they be split

• Considerations
• Do the same conditions make sense?
• Time of day yes
• Watcher yes
• Presentity state ?
• Service state ?
• Device state ?
• When do we need the policy
• Upon subscription
• Upon input state change

31
Issue E

• Considerations
• Action currently includes both
• Polite block affects data
• Overhead
• If they are separate, users will normally need to
  set both
• Continuum
• Rejection of a subscription is just the extreme
  end of a privacy continuum

• Data Model Impact
• Data processing doesnt include subscription
  acceptance/rejection - would seem to argue for
  split
• Polite blocking is actually acceptance plus a
  specific composition policy!

32
Proposal Logical Split, Physical Join

• Logically, there are three policy documents
• What to do when you get a SUBSCRIBE
• Subscription Policy
• How to generate a document when an input changes
• Composition Policy
• How to filter a document for privacy
• Privacy Policy

• Each policy document has conditions, actions and
  transformations specific to it
• Each policy document has conditions, actions and
  transformations applicable to all
• Use XML namespaces to indicate which conditions,
  actions, transformations are for subscription,
  composition or filter policy

33
Subscription Policy

• Conditions
• Identity, sphere, validity
• Actions
• Reject, confirm, accept
• Transformations

34
Composition Policy

• Conditions
• Identity, sphere, validity types of inputs,
  numbers of inputs, etc.
• Actions
• Polite-block, concatenate, etc.
• Transformations

35
Privacy Policy

• Conditions
• Identity, sphere, validity
• Actions
• Transformations
• See later slides

36
Issue F What does document apply to

• Problem
• Current document makes transformations
  conditioned on tuple type
• Two layer conditions ugly
• Henning proposed policy documents apply to tuples

• Data Model Implication
• Policy documents apply to processing of presence
  document
• Can condition policy document on existence of
  specific service, device or their characteristics
• Can specify transformations that apply to
  specific service, device, presentity
• Proposal
• Punt per-tuple privacy

37
Issue G What kind of privacy transformations do
we want?

• Provide tuples of particular schemes/class/type?
• Provide all RPID elements?
• How to provide note? Document-wide? Per-tuple?
• RPID elements by name and class/URI scheme/type
  of tuple?

• Not a data model issue (mostly), a scope issue
• Use cases really unclear
• Proposal
• Absolute minimum for now
• Provide services by URI or scheme
• Provide devices by device ID
• Provide attributes by name
• Not on a tuple by tuple basis

38
Motivating Use Cases

• Give Bob information on my voip service, but not
  my telephony service
• Allow Jane to see my Vonage service, but not my
  work service
• Dont show anyone what Im doing right now

39
Presence Data Model

• What is a tuple anyway?

40
Motivation

• Need to have a common understanding of what
  presence documents really mean in order to
  achieve interoperability
• Consistent understanding and interpretation of
  our various extensions
• Only one way to interpret a document
• Many of our drafts are caught in loops due to
  lack of understanding

41
Tuple Design Team

• Points of Debate
• One vs. Many Presentity
• Devices or not
• Resources and Capabilities as Device Information
• Correlation of services across devices
• Meaning of idle

42
One vs. Many Presentity

• Model allows one presentity per document
• Inherently presence models one presentity
• Some concerns about inability to retain
  conflicting information from multiple sources
• Proposals to handle conflicts at attribute level

• Design team conclusion
• Retain current model of one per document

43
Devices or Not

• What some folks thought of as a device previously
  is now called a service
• What is the definition of a device?
• How to model distributed devices?
• Bluetooth headset mobile phone

• Design team conclusion
• Devices are useful, we should keep them
• Not clear what does in them
• Not clear how to define them

44
Resources and Capabilities

• Is it useful to say certain things about devices
• CPU
• Memory
• Bandwidth
• Screen size
• Video camera, speakers
• Problem application may not get access to these
  resources
• If it does, they become service characteristics

• Design Team Conclusion
• Devices not useful for conveying resource and
  capability information

45
Correlation

• Is it useful to know that
• Two services run on the same device
• A service runs across multiple devices
• Former most interesting
• Helps in selecting a service because a human can
  extract service preference from device
  correlation
• Send an SMS to the device I just called

• Design Team Conclusion
• Correlation useful
• Service states cannot be automatically inferred
  from other services on the same device

46
Meaning of Idle

• Model proposes idle interpretation is dependent
  on service, device or presentity
• Device no input into device (meaning in existing
  IM systems)
• Service no input into service
• Presentity no input to person?

• Other approaches
• Have it mean probability of responding
• How to measure?
• Have it be specific to a type of input
• Keyboard
• Mouse
• No conclusion

47
Multiple Inserts

• Relegated to a separate draft
• draft-rosenberg-simple-xcap-multiple-00.txt
• Defines proposal weve been debating on the list

48
Multiple Inserts

• Issue referential integrity
• We have a few places where one document contains
  a reference to another
• Server doesnt guarantee referential integrity
  now very hard
• Doesnt fit well with reject if not good model

• Multiple inserts would allow server to check
  referential integrity
• Client would need to PUT something so that result
  is fully consistent
• Allow app usages to specify referential integrity
  constraints
• Takes us a major step closer to a DB protocol
• Is that what we want?
• Is this the right group to do it?