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 A C PUT /users/joe/doc1/foo/*[2][name()=“bat”] B A B C Selects all children of foo {baz,bar} Of those, selects second {bar} Of those, selects the one whose 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 data NO DATA CHANGE PUT using suggested data 200 OK DATA 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 need to be (validation a MUST) I believe this is OK for PUT as 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 foo/bar[1]|foo/bar[2] A B C Node selector 1Node 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 if a.No other modification touches its grandparents or higher antecedents b.Parent has changed only by having new children c.New children don’t interfere with the way the element is addressed a.Don’t get inserted before it, if it is addressed positionally b.Don’t have same attributes as used to address it 2.Content of the URI is the same if a.No other modification touches that element b.No other modification touches its children

Example Problem Case PUT test Uh oh test Uh oh GET 404! Problem here is that a new element is given an attribute/value used in the 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(N 2 ) 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 Can’t do this Has to be this

Issue 6 Proposal Add the [.=“X”] predicate Can then ask for an element by content GET

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 content content content content content content is it legal to have an XCAP reference of the

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 Does this rule apply? How to handle subscription? What presence data will they see?

Current Set Conditions – - AOR of watcher – - watcher is anonymous – - from common policy Actions – 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 home foo

Transformations –Inclusion set –Inclusion set –Inclusion set –Inclusion set –Inclusion set –Inclusion set –Inclusion set –No-time: leave off time –Full: include time –Inclusion set –Inclusion set –Inclusion set –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

Issue 1: Default provide-contact Expectation is that most common permissions will allow watcher to see contacts Existence of a permission means you must explicitly give it out –Privacy-safe requires that lack of 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 <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:xcap="urn:ietf:params:xml:ns:xcap-must-understand" xmlns:xsi=" Bill Doe <list name="close-friends" subscribeable="true"> Joe Smith

List Issue 1: External References 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 Proposal on list to make it a child Problem: makes it very hard to select elements by URI! Proposal: keep as is

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

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, 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 1Service 2Service 3 Device 1Device 2 Service: A means for communications characterized by a URI that can be used for accessing that communications Device: A physical entity used for communications with a specific service. Presentity: The user or entity 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 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 –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