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:[email protected]</uri> <uri>sip:[email protected]</uri></acl>
Can’t do this
<acl> <uri id=“sip:[email protected]”/> <uri id=“sip:[email protected]”/></acl>
Has to be this
Issue 6 Proposal
• Add the [.=“X”] predicate
• Can then ask for an element by content
<acl> <uri>sip:[email protected]</uri> <uri>sip:[email protected]</uri></acl>
GET http://server/xcap-root/auid/users/joe/acl/uri[.=“sip:[email protected]”]
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:[email protected]" subscribeable="true"> <entry name="Bill" uri="sip:[email protected]"> <display-name>Bill Doe</display-name> </entry> <list name="close-friends" uri="sip:[email protected]" subscribeable="true"> <entry name="Joe" uri="sip:[email protected]"> <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:[email protected]”> 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