XCAP Open Issues

1. XCAP Open Issues May 2004 Interim Jonathan Rosenberg dynamicsoft

2. 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 1: Schema Extensibility

3. 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 Issue 2: Positional Insertions

4. 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> Selects all children of foo {baz,bar} <foo> <baz>A</baz> <bat>B</bat> <bar>C</bar> </foo> Of those, selects second {bar} Of those, selects the one whose name is bat {}

5. 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)

6. 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

7. Proposed Server Data Method PUT w/o needed data 409, body suggests data NO DATA CHANGE PUT using suggested data 200 OK DATA CHANGE Server Client

8. User PUTs data, server doesn’t modify, no validation at all User PUTs data, server doesn’t modify, but it will reject the request if its invalid for any reason – schema, URI uniqueness, etc. User PUTs data, server modifies data before storing Drawing the Line Clearly PUT This is where we needto be (validation a MUST)I believe this is OK for PUTas defined in RFC 2616 Clearly POST

9. 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? Issue 4: Element Separator

10. 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.

11. 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

12. 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 Issue 5: Multiple Insertions

13. 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

14. 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

15. Curing Idempotence?

16. 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

17. 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?

18. 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

19. Proving Idempotence • URI points to the same element if • No other modification touches its grandparents or higher antecedents • Parent has changed only by having new children • New children don’t interfere with the way the element is addressed • Don’t get inserted before it, if it is addressed positionally • Don’t have same attributes as used to address it • Content of the URI is the same if • No other modification touches that element • No other modification touches its children

20. 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] Problem here is that a new elementis given an attribute/value used inthe addressing of another 404!

21. 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

22. 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

23. Do we want this?

24. 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

25. 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 Issue 6: Selecting Elements by Text Content <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

26. Add the [.=“X”] predicate Can then ask for an element by content Issue 6 Proposal <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”]

27. 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

28. 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

29. 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"]

30. 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

31. 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 Reminder: Etags

32. 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

33. 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

34. 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

35. 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

36. Presence Authorization Rules

37. 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?

38. 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 Current Set <provide-placetype> <tuples-whose> <placetype>home</placetype> <class>foo</class> </tuples-whose> </provide-placetype> <provide-placetype> <all-tuples/> </provide-placetype>

39. <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 Transformations

40. 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>

41. 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

42. 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

43. 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  |      |           |      |           |      +-----------+

44. 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: Rule Scope

45. 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

46. 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)

47. List Usage

48. 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>

49. 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

50. 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>