XCAP

XCAP

Jonathan Rosenbergdynamicsoft

Changes in Main Spec• Removed POST usage• Clarified the meaning of

PUT for inserts vs. modifies• Added AUID grammar• Specified a grammar for

xpath-style expressions – small subset of Xpath

• Java form for vendor specific AUIDs

• Using Etags, not modification times

• No batching provided – design your schemas carefully

• Clarified server awareness needed of the AUID and all namespaces in the document

• Clarified that other usages can specify auth policies

• Updated Examples• No content in error

responses

Filename?

• Does the xcap URI have a filename extension in it?– http://

xcap.example.com/services/presence-lists/users/joe/mybuddies.xml

– http:// xcap.example.com/services/presence-lists/users/joe/mybuddies

• Proposal: with filename extension

MIME Types

• What MIME type is indicated in PUT request and GET response?– Application/xml, text/xml, text/plain,

application/presence-list+xml, new one?• Proposal:

– Application/xml when its an XML document• Seems better than text/xml since the consumer is not

a user – rendering is not useful– Text/plain for attributes

Event Package

• What is the fate of the event package?• Many big issues

– Integrate with configuration framework?– SyncML?

• Proposal– Move forward with xcap, xcap-auth, xcap-list

first, visit package second

Etag Scope• Current spec associates a

separate Etag with each XML component

• If you update one component, all ancestors and descendants are updated

• Problem: how does the client know what those other etags are? – Complex

• Proposal I– Ancestor and descendant

tags are the same as the new tag

– Means client can compute the tags locally

• Proposal II– Just maintain an Etag for

the whole document

Etag Scope

• Proposal I pros– Allows for several

users to manipulate different sub-trees without stepping on each others toes

– But, do we need that?• CPCP?

• Proposal II pros– Simpler

• Recommendation:– Proposal II

Query v. Path

• Query approach:– http://xcap.example.com/presence-lists/users/

joe/mybuddies.xml?lists/list[@id=“1”]• Path approach:

– http://xcap.example.com/presence-lists/users/joe/mybuddies.xml/lists/list[@id=“1”]

Query v. Path• Benefits of Query

approach– Makes it easy for server to

figure out where doc ends and elements begin

• Benefits of Path approach– Hides implementation

details– Works better with existing

equipment• Query strings in PUT• Cache treatment of query

parameters

• Recommendation:– Path Approach

Error Reporting• Current revision has no special error reporting

– Operations which cause invalid schema return 409– Giving details on error is unlikely to help – doubtful an

automata can recover• However, there is a recoverable error

– Data interdependencies – setting a URI that already exists– Client should retry with new URI

• How to indicate this? – New response code – yuck– Some kind of XML in the body of the 409 –

allowed/possible?

XCAP List

• Changes in this revision– Made it about generic resource lists – left hooks

for various “actions” to be taken against the list– Added support for external references to other

lists described by an XCAP URI

Subscription Auth Policy

• If subscribeable flag is true, who can subscribe?– Spec doesn’t say

• Proposal– It’s a matter of local policy– We can define an xcap usage later that defines

subscription permissions

XCAP Auth• Changes

– Added an <except> clause, so you can except a user, domain or list

– Removed boolean operators from accept-if– Removed rule permissions– Remove transformational permissions– Removed requested-namespace, requested-element, requested-

tuple, duration accept-if conditions– Show-tuple selects a tuple by tuple class, not id– Removed show-values– Removed compound permission AUID – later– Content permissions are applied BEFORE composition process

Open Issues

• Alignment with Geopriv• Lying and Polite Blocking

Why is Alignment Good?

• Geolocation and presence are intimately related

• We want to be able to deliver geoloc information in presence– Placetype is a start!

• Further enhances the SIMPLE value proposition

Exceptions

• Exceptions need to be treated carefully to work– Excepting a user from * is useless – its easy for a user

to get a new name– You have to drop an entire statement if you can’t

resolve an external reference for an exception– Exceptions don’t deny a user permissions – they allow

a convenience for enumerating a long list of people to whom a rule applies

Exceptions

• Example:– Allow example.com

except Bob– Allow example.com

except Judy• If I have both these

rules, and Bob subscribes, is he allowed?– YES!

• Matching operations need to be carefully specified– Foo.example.com same as

example.com?

• Geopriv has decided not to do exceptions initially

• If we want alignment, we need to drop them too– What does the group think

about this?

Conditions

• Current xcap-auth has conditional permissions– Accept-if

• But, conditions can make sense for any permission

• Better alternative:– All conditions are present in the <applies-to>

tag

Example

<statement> <applies-to> <anonymous>true</anonymous> </applies-to>

<accept/> <show-element>basic</show-element></statement>

Validity Condition

• Specifies the duration over which the statement applies

• Allows the server to “ignore” permissions automatically, instead of forcing the client to remove on expiration

– Client may not be connected– Assures privacy safety

• Good idea!

Sphere Condition• Allows a statement to apply if the

presentity’s sphere has some value• Dependent on inclusion of sphere in RPID• Nice idea, do we need it initially?

<statement> <applies-to> <sphere>work</sphere> <uri>sip:[email protected]</uri> </applies-to> <show-namespace>pidf-phone</show-namespace></statement>

Authentication Condition

• We can specify type of authentication that needed to be used

• BUT, will a *user* be able to usefully set this?– NO– They won’t understand security properties

• Proposal: remove

Permission Combining

• If multiple statements apply, how are permissions combined?– Current spec says UNION – but this only

makes sense for token types– Need to define rules for other types

• Boolean: OR operation– Requires TRUE to be more permissive

• Integer: MAX operation– Requires maximum to be more permissive

Explicit Confirmation

• Currently, a watcher is pending if there are no matching statements

• Might want to explicitly specify that I should always be asked to confirm subscriptions from a user (I.e., winfo)

• To do this, would add confirm-subscription boolean

Actions vs. Transformations• Terminology issue only• Geopriv has

– Actions: things to do if this statement matches– Transformations: ways to change data if this statement matches

• XCAP has– Acceptance policy: whether or not subscription is accepted– Content Policy: data to send

• Proposal to use geopriv terminology– More general– Consistent with other policy work– Also indicate in XML

Unified Document Structure

CommonRule

GeoprivRule

XCAPAuth

SIP Naming

GEOPRIV Doc

SIMPLE Doc

Common Rule Content

• Model Definition– Additive Permissions– Rule Structure

• Conditions– Validity, sphere, [uri], [domain], anonymous

• Actions– Accept subscription, confirm subscription

• Transformations– NONE defined – data specific

• Generic Terminology – PT = Presentity/Target

SIP Naming

• Common rules document can’t contain conditions for matching on users or domains– These are “using protocol” specific

• Need a small doc that defines sip-specific matching elements– <sip-uri>– <domain>

XCAP Auth Content

• Normative reference to common rule content and SIP URI doc

• Defines the transformational permissions– Show-element, show-namespace, show-contact,

show-note, show-all• Defines the supported permissions

application usage• Will be a much shorter document!

Lying

• Per list discussion, specifying lying policies in XCAP is out– Will be too much flexibility

needed

• Alternative– Client publishes false tuples– Server publishes false

tuples– XCAP policy selects the

appropriate tuple by class

• Problem– For server case, how

does client know which tuple to select?

• Provisioning – xcap usage?

• User does it manually

• Proposal:– Xcap usage as a follow

on activity

Polite Blocking

• Problem– Currently, no clear way

to do polite blocking– Need this in first rev

• Proposal I– Accept the subscription

and use lying to send them a fake tuple

• Proposal II– Change “accept”– Make it “subscription-

decision” with values “accept” and “politely-block”

– Politely-block < accept for combining purposes

• Proposal III– Do proposal II now, allow I

later– RECOMMENDATION