XCAP Open Issues

1
XCAP Open Issues

• May 2004 Interim
• Jonathan Rosenberg
• dynamicsoft

2
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 wont
  be validated)
• Can still validate parts that are known
• No disagreements on the list

3
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

4
Example
ltfoogt ltbazgtAlt/bazgt ltbargtClt/bargt lt/foogt
PUT http//server.com/xcap-root/example/users/joe
/doc1/foo/2name()batltbatgtBlt/batgt
Selects all children of foo baz,bar
ltfoogt ltbazgtAlt/bazgt ltbatgtBlt/batgt
ltbargtClt/bargt lt/foogt
Of those, selects second bar
Of those, selects the one whose name is bat
5
Patterns

• To insert something as the nth foo
  elementparent/foonunique-characteristicwher
  e unique-characteristic is an expression that
  differentiates the new thing from the current nth
  thing, if present
• To insert something as the nth elementparent/n
  unique-characteristicwhere unique-characterist
  ic 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 were 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
Drawing the Line

1. User PUTs data, server doesnt modify, no
   validation at all
2. User PUTs data, server doesnt 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
This is where we needto be (validation a MUST)I
believe this is OK for PUTas defined in RFC 2616
Clearly POST
9
Issue 4 Element Separator

• The issue that wont 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?

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 cant appear anywhere in
  document selector
• XCAP is all about constraining URI structure

12
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

13
URI Structure
http//server.com/xcap-root/AUI/users/joe/doc/foo
/bar1foo/bar2
ltfoogt ltbargtAlt/bargt ltbargtBlt/bargt
ltbargtClt/bargtlt/foogt
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?
• Dont 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 dont interfere with the way the
  element is addressed
• Dont get inserted before it, if it is addressed
  positionally
• Dont 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
ltfoogt ltbar id1/gt ltbar id2/gt lt/foogt
PUT http//server/xcap-root/auid/users/joe/foo/ba
r_at_id1foo/bar3ltbar id1gttestlt/bargt ltbar
id1gtUh ohlt/bargt
ltfoogt ltbar id1gttestlt/bargt ltbar id2/gt
ltbar id1gtUh ohlt/bargt lt/foogt
GET http//server/xcap-root/auid/users/joe/foo/ba
r_at_id1foo/bar3
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
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

ltaclgt lturigtsipbob_at_example.comlt/urigt
lturigtsipalice_at_example.comlt/urigt lt/aclgt
Cant do this
ltaclgt lturi idsipbob_at_example.com/gt lturi
idsipalice_at_example.com/gt lt/aclgt
Has to be this
26
Issue 6 Proposal

• Add the .X predicate
• Can then ask for an element by content

ltaclgt lturigtsipbob_at_example.comlt/urigt
lturigtsipalice_at_example.comlt/urigt lt/aclgt
GET http//server/xcap-root/auid/users/joe/acl/ur
i.sipbob_at_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
ltaTagsgt    ltaTaggt       ltbTagsgt          ltbTag
at1"1"gt content lt/bTaggt          ltbTag at1"2"gt
content lt/btaggt       lt/bTagsgt       ltothertags
at2"x"gt content lt/othertagsgt    lt/aTaggt   
ltaTaggt        ltbTagsgt          ltbTag at1"3"gt
content lt/bTaggt          ltbTag at1"4"gt content
lt/btaggt       lt/bTagsgt       ltothertags
at2"y"gt content lt/othertagsgt    lt/aTaggt
lt/aTagsgt is it legal to have an XCAP reference
of the form .../document/aTags/aTag/bTags/bTag_at_a
t1"1"
30
Issue 7 Considerations

• Can eliminate this by mandating unique results in
  each step
• Server thus needs to check this
• Hard if youre 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
Reminder Etags

• Current specification doesnt 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

32
Issue 8 Finding out scope of change

• Problem
• Document has two buddy lists, X and Y
• X has etag1, Y has etag1, doc has etag1
• Two xcap clients, A and B have full doc and etag
• A does conditional PUT to X conditioned on etag1
• Succeeds, updates X. New etag for X is 2, Y is 1,
  doc is 2
• B does a conditional PUT to X conditioned on
  etag1
• 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 doesnt 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
  (doesnt 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
ltrulesetgt ltrulegt ltconditionsgt
lt!-- CONDITIONS --gt lt/conditionsgt
ltactionsgt lt! ACTIONS --gt
lt/actionsgt lttransformationsgt lt!
TRANSFORMATIONS --gt lt/transformationsgt
lt/rulegt lt/rulesetgt
Does this rule apply?
How to handle subscription?
What presence datawill they see?
38
Current Set

• Conditions
• ltidentitygt - AOR of watcher
• ltanonymousgt - watcher is anonymous
• ltspheregt - from common policy
• Actions
• ltsub-handlinggt
• 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

ltprovide-placetypegt lttuples-whosegt
ltplacetypegthomelt/placetypegt
ltclassgtfoolt/classgt lt/tuples-whosegt lt/provide-pla
cetypegt
ltprovide-placetypegt ltall-tuples/gt lt/provide-pla
cetypegt
39
Transformations

• ltprovide-contact-urigt
• Inclusion set
• ltprovide-activitygt
• Inclusion set
• ltprovide-tuplesgt
• Inclusion set
• ltprovide-classgt
• Inclusion set
• ltprovide-contact-typegt
• Inclusion set
• ltprovide-relationshipgt
• Inclusion set
• ltprovide-spheregt
• Inclusion set

• ltidle-detailgt
• No-time leave off time
• Full include time
• ltprovide-idlegt
• Inclusion set
• ltprovide-placetypegt
• Inclusion set
• ltprovide-privacygt
• Inclusion set
• ltprovide-unknown-statusgt
• Next slide

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

ltprovide-unknown-status namefoogt
ltall-tuples/gt lt/provide-unknown-statusgt
41
Issue 1 Default provide-contact

• Expectation is that most common permissions will
  allow watcher to see contacts
• Existence of a ltprovide-contactgt permission means
  you must explicitly give it out
• Privacy-safe requires that lack of
  ltprovide-contactgt 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     --gt Document  -gt
Filtering       Source       \\       
//                   \\------//        
---------    /  \------/                
                                     /     
          -----------                   
               /                                
                    --------- /   
------------                 ------------   
  Presence /     Composition              
   Presence         Source       
Policy                      Auth          
  ---------      (TBD)     
                                
                              
                                          
--------                            
                                 
------------                 ------------   
                                              
                              
V                                                 
        V        ------         
-----------                      -----------
   ////      \\\\                       
------                        Post       
     Filtered      ///      \\\     
Candidate     Processing   lt--- Presence 
lt--   Watcher       Presence     
Composition      Document        Filter  
lt--- Document     \\\\      ////     
               \\\      ///                
       ------                           
------                            
             -----------                     
-----------                           
                  V      -----------
                     Final         
Presence       Document                 
                     -----------
44
Issue 4 Rule Scope

• Question do rules match subscriptions/notificatio
  ns 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

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
lt?xml version"1.0" encoding"UTF-8"?gt ltresource-l
ists xmlns"urnietfparamsxmlnsresource-lists"
xmlnsxcap"urnietfparamsxmlnsxcap-must-und
erstand" xmlnsxsi"http//www.w3.org/2001/XMLSch
ema-instance"gt ltlist name"friends"
uri"sipfriends_at_example.com" subscribeable"true"
gt ltentry name"Bill" uri"sipbill_at_example.com
"gt ltdisplay-namegtBill Doelt/display-namegt
lt/entrygt ltlist name"close-friends"
uri"sipclose-friends_at_example.com"
subscribeable"true"gt ltentry name"Joe"
uri"sipjoe_at_example.com"gt
ltdisplay-namegtJoe Smithlt/display-namegt
lt/entrygt ltentry-refgthttp//www.example.com/x
cap/resource-lists/users/a/obuddies/resource-lists
/list_at_nameco-workers/entry_at_namejacklt/ent
ry-refgt ltexternalgthttp//www.example.org/xcap/reso
urce-lists/users/a/foo lt/externalgt
lt/listgt lt/listgt lt/resource-listsgt
49
List Issue 1 External References

• ltentry-refgt 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 ltentrygt
• Proposal on list to make it a child
• Problem makes it very hard to select elements by
  URI!
• Proposal keep as is

ltentrygt lturigtsipuser_at_domainlt/urigt lt/entrygt
51
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

52
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

53
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

54
Approach II Example
ltsip-urisgt ltlist urisipfriends_at_example.comgt
http//www.example.com/xcap/resource-lists/users/
a/obuddies/ resource-lists/list_at_nameco-workers
lt/listgt lt/sip-urisgt
55
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

56
What is a Tuple
57
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?

58
Proposed Model
Presentity
Presentity The user orentity that is being
modeled
Service A means forcommunications
characterizedby a URI that can be usedfor
accessing that communications
Service 1
Service 2
Service 3
Device 1
Device 2
Device A physical entityused for
communicationswith a specific service.
59
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 ltdevicegt element which
  indicates one or more devices and their
  characteristics on which that service resides
• Device is thus another tuple attribute like the
  others

60
Benefit of this Model

• Easy transformation to device view
• A pivot operation which unions together services
  that have the same device
• Device isnt 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 ltdevicegt
• In tuples with no contact
• In tuples with contact

61
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)

62
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 Roberts examples document that
  elaborates on this