XCAP Open Issues

May 2004 Interim

Jonathan Rosenberg

dynamicsoft

Issue 1: Schema Extensibility

• Problem– Schema awareness used

for two purposes• Document validation• Determining where to

insert– Requiring schema

awareness limits extensibility

• PIDF extensions for example

• Proposal– Schema awareness only

used for validation– Where to insert must be

specified by client• Benefits

– Eliminates some of the PUT “magic”

– Allows extensibility (resulting data just won’t be validated)

– Can still validate parts that are known

• No disagreements on the list

Issue 2: Positional Insertions

• Currently, no way to insert an element in a specific place– Goes on end if its an insert

• Problems– A big one if schema

awareness not used to determine where to insert

– A limitation for schemas where position is significant (i.e., CPL)

• Proposal– Allow the “*” operator to

select all children of a node– Allow multiple predicates

(i.e., multiple [])– Allow name() function as a

predicate to pick an element by name

• These allow positional insertions

• Was agreed on list

Example

<foo> <baz>A</baz> <bar>C</bar></foo>

PUT http://server.com/xcap-root/example/users/joe/doc1/foo/*[2][name()=“bat”]

<bat>B</bat>

<foo> <baz>A</baz> <bat>B</bat> <bar>C</bar></foo>

Selects all children of foo {baz,bar}

Of those, selects second {bar}

Of those, selects the onewhose name is bat {}

Patterns

• To insert something as the nth foo element:parent/foo[n][unique-characteristic]where unique-characteristic is an expression that differentiates the new thing from the current nth thing, if present

• To insert something as the nth element:parent/*[n][unique-characteristic]where unique-characteristic is an expression that differentates the new thing from the current nth thing, if present

• Unique characteristic can be– Element name– Value of an attribute– Possibly content (other issue)

Issue 3: PUT v. POST

• Is what we’re doing a PUT or a POST?• Currently is unclear because

– The server ccan modify data– Modeled as a virtual application – ugly

• PUT litmus test– GET(PUT(x))=x– Idempotence

• POST is a slippery slope, will invite scrutiny

Proposed Server Data Method

Client Server

PUT w/o needed data

409, body suggests dataNO DATA CHANGE

PUT using suggested data

200 OKDATA CHANGE

Drawing the Line

1. User PUTs data, server doesn’t modify, no validation at all

2. User PUTs data, server doesn’t modify, but it will reject the request if its invalid for any reason – schema, URI uniqueness, etc.

3. User PUTs data, server modifies data before storing

Clearly PUT

Clearly POST

This is where we needto be (validation a MUST)I believe this is OK for PUTas defined in RFC 2616

Issue 4: Element Separator

• The issue that won’t die• History:

– ?• Problems with proxies

• Not a good model

– #• Executed locally, we need

server based

– Nothing• Hard to implement

– ~• Might exist in host path

component (there is precedent)

• Desired characteristics– Disallowed in XML names– Allowed in HTTP URI

abs_path– Usually not used in host

paths

• Does existence in host paths matter?

HTTP Text

A transparent proxy MUST NOT rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above to replace a null abs_path with "/". Note: The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been known to rewrite the Request-URI.

Picking

• RFC2396 “mark” characters are {- _ . ! ~ * ‘ ( ) }

• Of these XML disallows {! ~ * ‘ ( ) _ (alone) . (alone)

• Proposal: single quote “’”

• Mandate that this can’t appear anywhere in document selector– XCAP is all about constraining URI structure

Issue 5: Multiple Insertions

• Problem(?)– XCAP currently allows

manipulation of a single element or attribute at a time

– Requires multiple operations to add several buddies

– Some have complained about this limitation

• Proposal on list to allow for manipulation (get, insert, modify) of multiple elements

URI Structure

http://server.com/xcap-root/AUI/users/joe/doc/foo/bar[1]|foo/bar[2]

<foo> <bar>A</bar> <bar>B</bar> <bar>C</bar></foo>Node selector 1 Node selector 2

Union “|” operator

Interpretation

• URI represents a resource that is a “view” of a portion of the document

• GET on the URI returns that view• PUT on the URI sets the view to the value

in the body• Key Constraint

– Series of URI components represent the URI after document modification is done

– Needed for idempotence

Curing Idempotence?

Idempotence Defined

• idempotence is the quality of something that has the same effect if used multiple times as it does if used only once

• HTTP PUT and GET are idempotent

Question

• How to find out where to insert each element so that the URIs match those elements in the final document?– Don’t want to search!

• Idea: implement as a series of individual operations

• Question: when does a series of individual PUT operations give you the property that it is equivalent to a PUT of the view?– i.e., when is this idempotent?

Proving Idempotence

• Basic proof– Assume PUT of an individual element is

idempotent– A sequence is idempotent if, after the

sequence• Each URI points to the same element• Value of the element is the same

– Doing the sequence at once is the same as one at a time if there are no errors in between

Proving Idempotence

1. URI points to the same element ifa. No other modification touches its grandparents or

higher antecedentsb. Parent has changed only by having new childrenc. New children don’t interfere with the way the

element is addresseda. Don’t get inserted before it, if it is addressed positionallyb. Don’t have same attributes as used to address it

2. Content of the URI is the same ifa. No other modification touches that elementb. No other modification touches its children

Example Problem Case

<foo> <bar id=“1”/> <bar id=“2”/></foo>

PUT http://server/xcap-root/auid/users/joe/foo/bar[@id=“1”]|foo/bar[3]

<bar id=“1”>test</bar><bar id=“1”>Uh oh</bar>

<foo> <bar id=“1”>test</bar> <bar id=“2”/> <bar id=“1”>Uh oh</bar></foo>

GET http://server/xcap-root/auid/users/joe/foo/bar[@id=“1”]|foo/bar[3]

404!

Problem here is that a new elementis given an attribute/value used inthe addressing of another

Server side algorithm I – Try and Fail

• Put each element, one at a time

• Execute an internal GET on each URI in the request– Each has to return one thing

• Series of elements has to be the same as body of PUT

Server Side Algorithm II - Verify

• Need to verify the properties discussed previously

• These are hard to verify– For example, checking ancestry seems O(N2)

where N is number of elements inserted– Checking 1c grows with complexity of ways of

addressing element

Do we want this?

Issue 5a: Multiple Attributes

• So far, its been about multiple elements

• What about inserting multiple attributes?

• If we want it, XML-based attribute list body may make sense– Allows you to return more than one– However XML is not needed for that

• Recommendation: no

Issue 6: Selecting Elements by Text Content

• Problem (?)– Currently, elements can be

selected by• Position

• Attribute value

– No way to select an element by text content

– Requires schema to put all relevant indexing data into attributes, even when content would be better

<acl> <uri>sip:bob@example.com</uri> <uri>sip:alice@example.com</uri></acl>

Can’t do this

<acl> <uri id=“sip:bob@example.com”/> <uri id=“sip:alice@example.com”/></acl>

Has to be this

Issue 6 Proposal

• Add the [.=“X”] predicate

• Can then ask for an element by content

<acl> <uri>sip:bob@example.com</uri> <uri>sip:alice@example.com</uri></acl>

GET http://server/xcap-root/auid/users/joe/acl/uri[.=“sip:bob@example.com”]

All is not rosy!

• What if element content is very large (e.g., paragraph of text)– Will be hard to index– May not want to store locally (Joel)

• Same could be true for attributes, though!• Meta-Issue

– Only want to select on things which are known to be indices

– The things that are indices are application usage specific

– XCAP selection rules are not application usage specific

Approaches

1. Allow application usages to define indices for their data– Complicates general purpose xcap code– Improves performance– Allows efficient purpose specific implementations

2. Allow attribute or content indices, leave it to clients to only use useful things as indices

3. Allow attribute indices, still leaving it to clients to only use useful things as indices, less likely to be problems

Issue 7: Unique Hops<aTags>    <aTag>       <bTags>          <bTag at1="1"> content </bTag>          <bTag at1="2"> content </btag>       </bTags>       <othertags at2="x"> content </othertags>    </aTag>    <aTag>        <bTags>          <bTag at1="3"> content </bTag>          <bTag at1="4"> content </btag>       </bTags>       <othertags at2="y"> content </othertags>    </aTag> </aTags>

is it legal to have an XCAP reference of the form .../document/aTags/aTag/bTags/bTag[@at1="1"]

Issue 7 Considerations

• Can eliminate this by mandating unique results in each step

• Server thus needs to check this– Hard if you’re using off-the-shelf Xpath– Desirable if you are implementing from scratch

• Performance better if each step has unique result

• Proposal: mandate uniqueness at each step

Reminder: Etags

• Current specification doesn’t reflect consensus from IETF 59

• Consensus was– Application usages define

scope of an etag• One choice is – applies to

whole document• Other choices – each buddy

list in a document has its own

– This is not mandatory behavior

• If client guesses wrong, may need to refetch broader scope

• Details– “Scope” is defined by parent

• All children of that parent have a different scope

• Parent has to exist in each document, or if not, scopes need to be declared for each parent that could exist

– A change in an element implies gives it etag X, and

• All other elements and attributes in the same “scope” get that etag

• All elements in higher scopes get that etag

• Siblings do not get that etag

Issue 8: Finding out scope of change

• Problem– Document has two buddy lists, X and Y

• X has etag=1, Y has etag=1, doc has etag=1

– Two xcap clients, A and B have full doc and etag– A does conditional PUT to X conditioned on etag=1– Succeeds, updates X. New etag for X is 2, Y is 1, doc is 2– B does a conditional PUT to X conditioned on etag=1– Fails

• Question: how does B know whether– Only X changed

• So only X needs GET to sync up

– Entire document changed• Entire document needs to be GET to sync up

Issue 8 Solutions

• Solution A– Use SIP event package, it will tell you what changed and the

new etag

• Solution B– Client assumes only innermost scope– If it was wrong, later PUTs in a broader scope will fail, in that

case, get the next most encompassing scope• Orthogonal to Solution A

• Solution C– Some kind of indication in the body of the 412– Not clear its allowed

• Solution D– Go back to document wide etags

Issue 9: Knowing Supported Namespaces

• Previously, it was important to know supported namespaces on server– Client had to be sure server knew them for

XCAP to work

• Now, its not so important– If server doesn’t know, no validation

• Do we want a way for the client to discover this?– Maybe – defer for later

Known To-Dos• Change MIME types to xcap specific ones, rather than

application/xml-fragment-body and application/xml-attribute-value • Terminology rework: xcap resources, not xcap servers• More examples(?)• Match AUID grammar with URI grammar• Clarify default namespace behavior• Document URI escaping and update examples• Clarify redirection behavior• Clarify filename extension behavior• Document if-none-match * to avoid creating new document but

otherwise allow modification• Look at WebDav 409 body format – useful to us (doesn’t seem so,

but more work needed)• Insertions go in at the end if position is not specified• Update etag behavior – etag scope is defined by application usage

Presence Authorization Rules

Authorization Document Format<ruleset> <rule> <conditions> <!-- CONDITIONS --> </conditions>

<actions> <!– ACTIONS --> </actions> <transformations> <!– TRANSFORMATIONS --> </transformations> </rule></ruleset>

Does this rule apply?

How to handle subscription?

What presence datawill they see?

Current Set

• Conditions– <identity> - AOR of

watcher– <anonymous> - watcher is

anonymous– <sphere> - from common

policy

• Actions– <sub-handling>

• Block – deny• Confirm – winfo• Polite-Block – lie• Allow - OK

• New transformation type: inclusion-set– Set of rules that identify to

which tuple a permission is applied

<provide-placetype> <tuples-whose> <placetype>home</placetype> <class>foo</class> </tuples-whose></provide-placetype>

<provide-placetype> <all-tuples/></provide-placetype>

Transformations

• <provide-contact-uri>– Inclusion set

• <provide-activity>– Inclusion set

• <provide-tuples>– Inclusion set

• <provide-class>– Inclusion set

• <provide-contact-type>– Inclusion set

• <provide-relationship>– Inclusion set

• <provide-sphere>– Inclusion set

• <idle-detail>– No-time: leave off time– Full: include time

• <provide-idle>– Inclusion set

• <provide-placetype>– Inclusion set

• <provide-privacy>– Inclusion set

• <provide-unknown-status>– Next slide

Provide Unknown Status

• Only applies to content for which there is no schemas for explicit permissions known to the server– Avoids overlap with semantic approaches that

can be defined later

<provide-unknown-status name=“foo”> <all-tuples/></provide-unknown-status>

Issue 1: Default provide-contact

• Expectation is that most common permissions will allow watcher to see contacts

• Existence of a <provide-contact> permission means you must explicitly give it out– Privacy-safe requires that lack of <provide-contact>

means that no contact is given

• Does this give people heartburn?– No

Issue 3: Specifying Views

• Two models for authorization policy– Model I: Server composes, authorization policies

apply after that has been done– Model II: Authorization rules guide composition

• Seemed to be consensus around model I– Auth done after composition– May need to do more composition after auth to

combine tuples, its outside of our scope to control that– We should define data flow

Data Flow +---------+   |Presence |   | Source  |\   +---------+ \                   +-----------+                \                  |           |                 \   /------\      | Raw       |    //------\\   +---------+    \// Create \\    | Presence  |  || Privacy  ||-----+   |Presence |----|   View     |-->| Document  |->|| Filtering||     |   | Source  |     \\        //    |           |    \\------//       |   +---------+    /  \------/      |           |                     |                 /      ^          +-----------+       ^             |                /       |                              |             |   +---------+ /    +------------+                 +------------+    |   |Presence |/     | Composition|                 | Presence   |    |   | Source  |      | Policy     |                 | Auth       |    |   +---------+      | (TBD)      |                 |            |    |                    |            |                 |            |    |           +--------|            |                 |            |    |           |        +------------+                 +------------+    |           |                                                         |           V                                                         V        ------          +-----------+                      +-----------+    ////      \\\\      |           |       ------         |           |   |  Post        |     | Filtered  |    ///      \\\      | Candidate |  |   Processing   |<---| Presence  |<--|   Watcher  |     | Presence  |   |  Composition |     | Document  |   |   Filter   | <---| Document  |    \\\\      ////      |           |    \\\      ///      |           |        ------          |           |       ------         |           |          |             +-----------+                      +-----------+          |          |          |          |          V

     +-----------+      |           |      | Final     |      | Presence  |      | Document  |      |           |      |           |      +-----------+

Issue 4: Rule Scope• Question: do rules match

subscriptions/notifications or tuples?

• Model A: Tuples– When data changes, for each

tuple i in presence document• Find set of rules that match I

– Based on watcher, time/day, state of I

• Apply transformations on tuple I

– Concatenate tuples– Apply composition policy– Send NOTIFY

• Model B: Notifications– When data changes

• Find rules that match document

– Based on watcher, time of day, etc.

• Apply transformations to document

• Apply composition policy• Send NOTIFY

• Why model A?– Current spec has an additional

set of conditions in inclusion-set

• Push it all into conditions– Conditions based on status

ambiguous for model B

Issue 4

• Model A complicates sub-handling– Really want a separate document format to

define how to handle subscription

• Model A differs from other systems• Model A unclear for content outside of a

tuple• Handling ambiguity

– Condition fails if its ambigous about whether it applies

Stepping Back

• We need to finish• This can get really complicated• We have a model on how to extend later

– Macros– Pipelining

• Lets do, for now– Provide tuples by class and URI scheme– Provide RPID elements globally (binary)– Provide contact, note globally (binary)

List Usage

Current structure<?xml version="1.0" encoding="UTF-8"?><resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:xcap="urn:ietf:params:xml:ns:xcap-must-understand" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <list name="friends" uri="sip:friends@example.com" subscribeable="true"> <entry name="Bill" uri="sip:bill@example.com"> <display-name>Bill Doe</display-name> </entry> <list name="close-friends" uri="sip:close-friends@example.com" subscribeable="true"> <entry name="Joe" uri="sip:joe@example.com"> <display-name>Joe Smith</display-name> </entry> <entry-ref>http://www.example.com/xcap/resource-lists/users/a/obuddies/resource-lists/list[@name=“co-workers”]/entry[@name=“jack”]</entry-ref><external>http://www.example.org/xcap/resource-lists/users/a/foo </external> </list> </list></resource-lists>

List Issue 1: External References

• <entry-ref> allows you to have an entry that is by reference rather than by value– Avoids duplicating data in cases where a user

appears in multiple lists

• Question: scope– Same document– Same server– Other servers?

• Proposal: same server

List Issue 2: Whither URI

• Currently, URI is an attribute of <entry>

• Proposal on list to make it a child

• Problem: makes it very hard to select elements by URI!

• Proposal: keep as is

<entry> <uri>sip:user@domain</uri></entry>

List Issue 3: Name

• Currently, entry has two attributes– Optional “name”– Mandatory “URI”

• Name exists as an alternate index• Question:

– Can we just drop name, use URI as index?– Will be a problem if URIs are equal by string comparison,

unequal by URI matching rules• Ignore this case?

• If we keep– Need to clarify uniqueness property– Server rejects requests if not unique

• Proposal: drop name

List Issue 4: List URI Uniqueness

• SIP URI for lists has to be unique– Those URI are buried within each document– Makes it hard, when adding a list, to determine if its

unique– Makes it hard, when getting a list SUBSCRIBE, to find

the right list

• In other words, SIP URI for a list is an index, but appears nowhere as an index

• Two approaches– Approach I – leave it alone

Approach II – Separate Index

• Define an application usage as “list of buddy lists”– A flat list of entries– Each entry has an index equal to the SIP URI of the buddy list– Value of each entry is a pointer to the membership, present in a

resource-list document as currently defined

• Remove “subscribable” flag from resource-list document– Also remove SIP URI – rather, use some other index

• There can only be one instance of the “list of lists” document

Approach II Example

<sip-uris> <list uri=“sip:friends@example.com”> http://www.example.com/xcap/resource-lists/users/a/obuddies/ resource-lists/list[@name=“co-workers”] </list></sip-uris>

Approach II Pros/Cons

• + Nicely separates concepts of SIP event list from a list of my friends

• + Provides a single place where there is an index

• - Splits a buddy list into two documents– Interactions with ad-hoc list seem better with

approach II though

What is a Tuple

RPID talks about four types

• Device– Phone, PDA, PC

• Service– Telephony, IM, SMS, email

• Presentity– The user themselves

• In-Person– The user as a

communications medium

• However– These are still not defined– Its hard to decide whether

RPID attributes apply to one and/or the other

– Device problems• What is the meaning of

the contact URI

– In-Person• How different from

presentity?

Proposed Model

Presentity

Service 1 Service 2 Service 3

Device 1 Device 2

Service: A means forcommunications characterizedby a URI that can be usedfor accessing that communications

Device: A physical entityused for communicationswith a specific service.

Presentity: The user orentity that is being modeled

Mapping the Model to PIDF

• Presentity status appears in a tuple with no contact

• Each service is modeled with a tuple• A tuple can have a <device> element

which indicates one or more devices and their characteristics on which that service resides– Device is thus another tuple attribute like the

others

Benefit of this Model• Easy transformation to “device

view”– A pivot operation which unions

together services that have the same device

– Device isn’t special as a presence attribute for pivot!

– Resulting document is still a list of tuples, each representing a service

• Easy transformation to “presentity view”– A pivot that just unions

everything together– Result is a document with one

tuple with a contact representing one service, “communications”

• Eliminates need for “contact-type”– Tuple with no contact element

is “presentity” and “in-person”– Tuples with contacts are

“services”• Allows us to differentiate what

status information belongs in which places– Child of <device>– In tuples with no contact– In tuples with contact

Benefits of Model

• Nice tool for correlating services that exist on the same device– Device ID would be a meaningful URN

• For phones, the tel URI

– Allows correlation of device information received from non-presence sources (i.e., GPRS connectivity state) to affected services

– Allows differentiation of published data received from different devices (my PC publishing “available for IM” vs. my cell phone publishing that)

Proposed Path Forward

• Remove contact-type from RPID• Remove attributes that are device specific• Clarify presentity/service difference

through contact URI presence/absence• Proceed with result• Produce a separate document introducing

device concept and device attributes• Proceed with Robert’s examples

document that elaborates on this