XCAP Jonathan Rosenberg dynamicsoft Agenda XCAP Base XCAP

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 • ISSUE 5: Multiple Insertions – Deferred – Only validation • ISSUE 6: Select by Text • ISSUE 2: Positional Insertion • ISSUE 7: Unique Steps – Added • ISSUE 3: PUT v. POST – PUT – Client sets data • ISSUE 4: Separators – ~~ – No – Required • ISSUE 8: Etag Scopes – Document • ISSUE 9 a: Namespace Discovery – Through extension usage • ISSUE 9 b: Etags useless for insert – Documented

Other Changes • AU specifies uniqueness constraints • XCAP servers don’t do referential integrity • Resource interdependencies defined • Removed <mandatoryns> • 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> contentb </bar> <bar> contentc </bar> </foo> DELETE foo/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=“NS 1” xmlns: ns 1=“NS 1”/> <bar xmlns=“NS 2” xmlns: ns 2=“NS 2”/> </foo> foo/ns 2: bar Select this

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 Lists, lists and more lists

XCAP List • ISSUE 1: Scope of entryref – 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. w 3. org/2001/XMLSchema-instance"> <service uri="sip: mybuddies@example. com"> <resource-list>http: //xcap. example. com/resource-lists/ users/joe/index/~~/ resource-lists/list%5 b@name=%22 l 1%22%5 d </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-xcappackage • 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 profilename 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 recombination? 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? Pertuple? • 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 • Design Team Conclusion – Two services run on the same device – A service runs across multiple devices – Correlation useful – Service states cannot be automatically inferred from other services on the same device • 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

Meaning of Idle • Model proposes idle • Other approaches interpretation is – Have it mean probability of dependent on service, responding device or presentity – Device: no input into device (meaning in existing IM systems) – Service: no input into service – Presentity: no input to person? • 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 we want? • Is this the right group to do it?