XCAP

Jonathan Rosenberg

dynamicsoft

Agenda

• XCAP Base

• XCAP List

• XCAP Event Package

• XCAP Authorization Usage

• Presence Data Model

• XCAP Multiple Inserts

XCAP Base

Almost There!

XCAP Base

• ISSUE 1: Schema Awareness– Only validation

• ISSUE 2: Positional Insertion– Added

• ISSUE 3: PUT v. POST– PUT– Client sets data

• ISSUE 4: Separators– ~~

• 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

Other Changes

• AU specifies uniqueness constraints

• XCAP servers don’t do referential integrity

• Resource interdependencies defined

• Removed <mandatory-ns>

• 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

Issues Raised in WGLC

• DELETE Idempotency

• XPath Namespace Context

• ETag and DELETE

• Caching

DELETE Idempotency

• DELETE needs to be idempotent

• Won’t 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

  <foo>      <bar> contenta </bar>      <bar> contentc </bar>    </foo>

DELETEfoo/bar[2]

  <foo>      <bar> contenta </bar>      <bar> contentb </bar>      <bar> contentc </bar>    </foo>

DELETEfoo/bar[2]

  <foo>      <bar> contenta </bar>   </foo>

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

<foo> <bar xmlns=“NS1” xmlns:ns1=“NS1”/> <bar xmlns=“NS2” xmlns:ns2=“NS2”/></foo>

Selectthis

foo/ns2:bar

ETag and DELETE

• Etag is associated with a resource (URI)

• After DELETE, the resource doesn’t exist– Presumably 200 OK

doesn’t 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

Empty Content

• Pros– Makes etags useful for

all operations

• Cons– Hack– May interact with other

mechanisms– Complicates simple

cases

• Proposal– Document limitation

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 – won’t be picked up by server processing PUT

XCAP List

Lists, lists and more lists

XCAP List

• ISSUE 1: Scope of entry-ref– XCAP Root

• ISSUE 2: URI of <entry> attribute or child– Attribute

• ISSUE 3: name or URI as <entry> 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

<?xml version="1.0" encoding="UTF-8"?><rls-services xmlns="urn:ietf:params:xml:ns:rls-services" xmlns:rl="urn:ietf:params:xml:ns:resource-lists“ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <service uri="sip:mybuddies@example.com"> <resource-list>http://xcap.example.com/resource-lists/ users/joe/index/~~/ resource-lists/list%5b@name=%22l1%22%5d </resource-list> <packages> <package>presence</package> </packages> </service> <service uri="sip:marketing@example.com"> <list name="marketing"> <rl:entry uri="sip:joe@example.com"/> <rl:entry uri="sip:sudhir@example.com"/> </list> <packages> <package>presence</package> </packages> </service></rls-services>

Issues Since WGLC

• Embedded vs. External Resource Lists

• Simpler structure for RLS services doc

• Support for “membercode” from draft-hiller-uri-list-index

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

Simpler Structure

• Jari asks, “can’t we just define each RLS service by its resource list”?

• I don’t 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

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 don’t have this index

• Cannot be added, schema doesn’t support that type of extensibility

• Options– Ignore– Add attribute extensibility– Add “membercode” now

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

XCAP Package/Diff

Change is good

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

Bootstrapping points

• Client knows its username, password, but not applications– SUBSCRIBE sip:user@domain

Event: sip-profile;profile-name=application• Client knows username, password, and the

specific app usage– SUBSCRIBE sip:user@domain

Event: sip-profile;profile-name=application; app-id=resource-lists

• Client knows the specific document– SUBSCRIBE sip:user@domain

Event: sip-profile;profile-name=application; app-id=resource-lists;document=“user/index”

XCAP Diff Format

Relationship to directory

• Directory allows discovery of documents on startup

• Config framework allows discovery of documents on startup

• SUBSCRIBE to user@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

XCAP Auth Usage

Picking up the Pieces in light of a Data Model

Issue A: Sphere interpretation

• Problem– <sphere> as a

condition can be ambiguous

– What tuple are we talking about?

– Previously: if ambiguous, condition fails

• Data Model Impact– <sphere> is a

presentity characteristic

– There is only one per document

– Problem eliminated

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

Issue C: Post Privacy Composition

• Problem– What happens if

document, after privacy, has tuples which don’t 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

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

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

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

doesn’t include subscription acceptance/rejection - would seem to argue for split

– Polite blocking is actually acceptance plus a specific composition policy!

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

Subscription Policy

• Conditions– Identity, sphere, validity

• Actions– Reject, confirm, accept

• Transformations

Composition Policy

• Conditions– Identity, sphere, validity [types of inputs,

numbers of inputs, etc.]

• Actions– Polite-block, [concatenate, etc.]

• Transformations

Privacy Policy

• Conditions– Identity, sphere, validity

• Actions

• Transformations– See later slides

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

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

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

• Don’t show anyone what I’m doing right now

Presence Data Model

What is a tuple anyway?

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

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”

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

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

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

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

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

Multiple Inserts

• Relegated to a separate draft– draft-rosenberg-simple-xcap-multiple-00.txt– Defines proposal we’ve been debating on the

list

Multiple Inserts

• Issue – referential integrity– We have a few places

where one document contains a reference to another

– Server doesn’t guarantee referential integrity now – very hard

• Doesn’t 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?