1. XCAP Tutorial
Jonathan Rosenberg

2. Ground Rules This is a session for level setting
People are at different points
We will start from the beginning
NO QUESTION IS TOO STUPID
Disrespect will not be tolerated
Please interrupt and ask
PLEASE!

3. Agenda Understanding XML HTTP Concepts of Note XCAP Problem Definition
Basic XML Concepts
Namespaces
Schema
XPath in Brief
HTTP Concepts of Note
Etags
XCAP Problem Definition
XCAP Basics

4. XML Basics XML is a mechanism for representing structured data
Data is represented by a tree
Each node in the tree is an element
Elements have attributes
Attributes qualify the data
“Leaf” Elements can contain text content
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>

5. XML Basics XML Comments Elements can be empty XML Declaration
<el-name/> shorthand
XML Declaration
Version
Encoding
IETF uses UTF-8
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>

6. XML Terms Well-formed Valid
Meets basic constraints for all XML documents
Each open tag has a matching close
Unique attribute names
Valid
Meets the constraints defined by a schema or DTD

7. XML Namespaces Problem Example
Want to combine content from different systems into one document
What if both sources define the same name?
Example
Add information to address book on whether data is synced with PC
<state>synchronized</state>
Which state is it?
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>

8. XML Namespaces Solution: XML Namespace
<?xml version="1.0" encoding="UTF-8"?
xmlns:post=“
xmlns:sync=“
<post:address-book>
<!—This guy is a bozo --
<post:entry>
<post:name>Jonathan Rosenberg</post:name>
<post:postal>
<post:street paved=“true”>600 Lanidex Pl</post:street>
<post:city>Parsippany</post:city>
<post:state>NJ</post:state>
<post:country>USA</post:country>
</post:postal>
<post:ietf-participant/>
<sync:state>synchronized</sync:state>
</entry>
</address-book>
Solution: XML Namespace
Elements and attributes are bound to a namespace when defined
Namespace is identified with a unique URI
A prefix is bound to that URI through a declaration in the document
Each element is named with its qualified name
The prefix, followed by a colon, followed by the local-name

9. Importance of Namespaces
Namespaces are like option tags in SIP
Group a bunch of things together and give it a name
Are useful for talking about extensibility
Are useful for negotiating extensibility
Provide a generic grouping facility

10. XML Schema Need a way to define the constraints on an XML document
Analagous to a database schema
Similar to a grammar
W3C has specified two ways
DTD
Original method
Not an XML document
Limited expressiveness
Schema
Newer
XML-based
Much more expressive
Much more complex
Works well with namespaces
Trend is towards schema

11. Schema Example <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace=" xmlns:xs="
xmlns=" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="address-book">
<xs:complexType>
<xs:sequence>
<xs:element name="entry" minOccurs="0" maxOccurs="unbounded">
<xs:element name="name" type="xs:string"/>
<xs:element name=" " type="xs:string"/>
<xs:element name="postal">
<xs:element name="street" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
<xs:element name="state">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="NJ"/>
<xs:enumeration value="NY"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="country" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element name="ietf-participant"/>
</xs:schema>

12. XPath XCAP selection is based on XPath XPath problem statement
Happens to be a subset
Not a normative usage
XPath problem statement
How to point to specific pieces of an XML document
Example: “The third element named entry”
Example: “All of the elements in a document that have the attribute paved equal to true.”
XPath = XML Addressing

13. Basic Example Want to point to the email element
<?xml version="1.0" encoding="UTF-8"?
xmlns:post=“
xmlns:sync=
xmlns=“
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan R<name>
<postal>
<street paved=“true”>600 Lx Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
<sync:state>synchronized</sync:state>
</entry>
</address-book>
Want to point to the element
XPath expression address-book/entry/
Just like a unix filesystem path
Each “directory” identifies an element name

14. Positional Selectors
What if there are multiple elements with that name?
Can supply predicates which select one of the matching ones
Predicates appear in square brackets
One such predicate is position
Indicates which one by its place in the ordered sequence of matching elements
Select second bar: foo/bar[2]
Select first bar: foo/bar[1]
<foo>
<bar>Hello</bar>
<bar>There</bar>
</foo>

15. Select by Attribute Name
You can select elements that have attributes with specific values
<foo>
<bar attr=“1”>Hi</bar>
<bar attr=“2”>How</bar>
<bar stuff=“LOTR”>Are</bar>
</foo>

16. Selecting Elements The result of selecting an element includes
The element
Its children
Its attributes
Everything between open bracket of open element to close bracket of close element
XPath allows selecting multiple elements
XCAP does not use this feature

17. Selecting Attributes
An attribute is selected by prefixing its name with an
The selected object is JUST the value
Different from elements
Name would be redundant
<foo>
<bar attr=“1”>Hi</bar>
<bar attr=“2” bool=“y”>How</bar>
<movie stuff=“LOTR”>Are</bar>
</foo>

18. XCAP Problem Space Motivating use cases Buddy Lists
Authorization Policies
Hard state presence data

19. Buddy List Use Case Client wants to subscribe to a list of users
Subscribe List
Client wants to subscribe to a list of users
Send SUBSCRIBE to server using SIP event list extension
Server retrieves list associated with buddylist URI
Generates SUBSCRIBEs to them
Client can manage that list
Add, remove, modify entries
Subscribe Joe
Subscribe Bob
Subscribe Mary
Read
List
Write
List
Data
Manipulation
Server
Standard Ifaces
Client

20. Authorization Use Case
Subscribe Petri
User Hiroshi subscribes to Petri
No auth policy in place, generates a winfo NOTIFY to Petri
Petri needs to be able to set authorization decision for Hiroshi
Want to be able to set such policies outside of a subscription as well
Read
List
Write
List
Data
Manipulation
Server
winfo
Standard Ifaces
Client

21. Hard State Presence Management
Subscribe Petri
Hiroshi subscribes to Petri
Petri has been offline for weeks
Server sends NOTIFY with current presence state
Petri wants to control default state when offline
Set it to <activity>vacation</activity>
Notify
Read
PIDF
Write
PIDF
Data
Manipulation
Server
Standard Ifaces
Client

22. Functional Requirements
Create resource list/auth policies/default presence doc
Associate resource list/auth policies/default presence doc with URI
Have client define URI
Have server assign URI
Modify contents of resource list/auth policies/default presence doc
Extend resource list/auth policies/default presence doc in hierarchical way
Delete a piece of resource list/auth policies/default presence doc
Fetch current resource list/auth policies/default presence doc
Allow multiple clients to access and modify a shared resource list/auth policies/default presence doc

23. Performance Requirements
Protocol will be used on wireless air interfaces
Means that it is
unacceptable to push the entire resource list/auth policies/default presence doc when a change is needed
Unacceptable to get the entire resource list/auth policies/default presence doc when the client needs to look at it
Implies local cache
Pushing and pulling partial pieces of the data is essential
Invalidation of cached data
Synchronization of data

24. Key Observations Clearly a general problem here
Allowing a user to managed provisioned data that is accessed by a network application
Apply some basic design principles
Separate protocol machinery from data schema
Don’t box yourself into a corner with the data schema
Bandwidth efficiency important
Lower the deployment bar
This is a well-trod space
LDAP, ACAP, SNMP, relational DB cover related spaces, none successfully deployed to broad end client bases

25. XCAP Architecture Same as previous pictures
Network App
Same as previous pictures
Scope limited to client to XCAP server
Access from Network App could be XCAP
Acts as a client
There may be no network app
XCAP server is repository for client data
Not
Standardized
Not
Standardized
XCAP
Server
XCAP
Client

26. The Big “Aha”
XCAP is about clients getting, deleting and putting pieces of hierarchically organized data
Ideally XCAP should leverage technologies widely found in phones, PCs and other client devices
XCAP can just BE HTTP, by defining the URI hierarchy to extend into “web documents”
HTTP URIs can represent any resource
Don’t need to exist on a disk
Interpretation is up to the server
XCAP defines that interpretation

27. HTTP in Brief Clients invoke methods on server
GET – retrieve content
PUT – place content
POST – pass data to a process
HEAD – get meta-data, not content
OPTIONS – query server for capabilities
DELETE – remove a resource from a server
Requests and responses contain bodies

28. Fetch a document GET http://server.com/dir/foo HTTP/1.1 <foo>
<bar attr=“1”>Hi</bar>
<bar attr=“2” bool=“y”>How</bar>
<movie stuff=“LOTR”>Are</bar>
</foo>
HTTP/ OK
Content-Type: application/xml
Content-Length: …
<foo>
<bar attr=“1”>Hi</bar>
<bar attr=“2” bool=“y”>How</bar>
<movie stuff=“LOTR”>Are</bar>
</foo>

29. XCAP Scope Application Usages Naming convention for URIs
Details how you use XCAP for a new app (i.e., CPCP)
Server assigned data
Naming convention for URIs
Document selector – picks the “XML Document” based on a defined document hierarchy
Component selector – picks an element or attribute within the document
Using GET, PUT and DELETE for management of elements and attributes
Error content
Extensibility of data
Etag advice

30. Application Usage
Defines what an application needs to do to be used with XCAP
Define an Application Unique ID
Define the XML Schema for the data
Define data semantics
Specify naming conventions – binding between application and XCAP
Data interdependencies (aka server computed data)
Authorization policies

31. AUID Unique Identifier for each application Two sub-namespaces
IETF tree: tokens in RFC documents
IANA Registry
Vendor tree: proprietary data
Start with reverse DNS name of enterprise
Examples
IETF Tree
“resource-lists” draft-ietf-simple-xcap-list-usage
“pidf-manipulation” draft-isomaki-simple-xcap-pidf-manipulation-usage-00
“rules” draft-rosenberg-simple-rules
Vendor Tree
“com.example.customer-list”

32. AUID Grammar AUID = global-auid / vendor-auid global-auid = auid
auid = alphanum / mark
vendor-auid = rev-hostname "." auid
rev-hostname = toplabel *( "." domainlabel )
domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

33. Naming Conventions An app will have “hooks” into XCAP
Points of operation of application when XCAP is used
Need to define how that is done
Example: Presence List
Fetch document whose uri attribute of <resource-list> is equal to request URI of SUBSCRIBE
Example: Authorization
Fetch authorization policy documents underneath where username identifies the presentity

34. Data Interdependencies
In many cases a user defines all of their own data
PIDF manipulation usage
Authorization policies
In some cases a few pieces of it are “filled in” by the server
Resource list URIs for lists – need to be unique, can be server assigned
Client can also define them
Application usage specifies what pieces server fills in, and how

35. Modeling Server Computed Data
Think of the application usage as a client of XCAP
Handset puts a new resource list, URI not present (1)
Application learns of change (4)
Acting as a client, application modifies data, setting URI (5)
This is a model, not an implementation requirement
Impacts Etag usage (later)
Handset
Application
XCAP Server
Database
(1) PUT Resource List
(2) 200 OK
(3) store
(4) Data Change
(5) PUT (set URI)
(6) 200 OK
(7) store

36. Authorization Policies
Who is allowed to access (R/W) XCAP data?
Application specific
Policies are specified by application usage
XCAP defines a “default”
A user can read and write their own data
A user can only access their own data
Global data is readable by everyone, writeable by no one except privileged users

37. Definition Example Basic address book from before
Would author an RFC structured as follows

38. Document Contents AUID XML Schema Naming Conventions
Want this to be global
Pick an appropriate AUID
address-book
Add an IANA Considerations section registering the AUID
XML Schema
Include it
IANA registry for schema and namespace
Naming Conventions
No server app
No naming conventions
No data interdependencies
Default authorization policy

39. Semantics An address book is a series of <entry> elements
Each <entry> is information about an entry in the address book
It has a <name>, which is the use persons first and last name
It has an < > element, which contains the address of the person
It has a <postal> element that has the postal address

40. The Document Hierarchy
XCAP defines URIs as two parts
Document selector – chooses the XML document
Node selector – chooses the XML component (element, attribute)
XPath subset discussed previously
XML documents organized into a mandatory hierarchy
Borrows from ACAP concepts

41. Hierarchy Structure Top is the Root Services URI Next is the AUID
Identifies start of XCAP tree
Next is the AUID
Next is “users” or “global”
“users” are for per-user documents
“global” are for data that is not user specific – for reading by all users of the app
Within users, next is username
Underneath username is anything
Eventually leads to document

42. The Hierarchy Root services AUID 1 AUID 2 users global petri hiroshi
doc1
dir1

43. Example 1
adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>

44. Client Operations Retrieving Deleting Modifying Adding Document
Element
Attribute
Deleting
Modifying
Document
Element
Attribute
Adding
KEY CONSTRAINT Can only affect one element, attribute or document at a time

45. Fetching a Document
GET HTTP/1.1
adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
HTTP/ OK
Content-Type: application/adbook+xml
Content-Length: …
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>

46. Fetching an Element
GET
address-book/entry/name HTTP/1.1
adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
HTTP/ OK
Content-Type: application/xml-fragment-body
Content-Length: …
<name>Jonathan Rosenberg</name>

47. Fetching an Attribute
GET
HTTP/1.1
adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
HTTP/ OK
Content-Type: application/xml-attribute-value
Content-Length: …
true

48. Delete a Document
DELETE HTTP/1.1
adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
HTTP/ OK
NULL

49. Deleting an Element adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
DELETE
address-book/entry/name/ HTTP/1.1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
HTTP/ OK

50. Deleting an Attribute adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
DELETE
HTTP/1.1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
HTTP/ OK

51. Modify vs. Add Modify and Add look the same Behavior depends on URI
PUT Request
Body contains content
Behavior depends on URI
Server checks if resource exist
URI resolves to an existing doc, element in a doc, or attribute in an element
If not, the operation is add
New content is added such that
URI now resolves to the content in the body
Schema constraints are obeyed
Otherwise inserted after all siblings
If so, the operation is modify
New content replaces the content selected by the URI

52. Insert an Element adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
PUT
address-book/entry/phone HTTP/1.1 Content-Type: application/xml-fragment-body
<phone> </phone>
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<phone> </phone>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
HTTP/ OK

53. Modify an Element adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
PUT
address-book/entry/name HTTP/1.1 Content-Type: application/xml-fragment-body
<name>Jonathan D. Rosenberg</name>
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan D. Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
HTTP/ OK

54. Server Error Handling
Server error handling is specified in HTTP specification
Most XCAP-specific cases are details within 404 or 409
409 (Conflict) The request could not be completed due to a conflict with the current state of the resource.
404 (Not Found) The server has not found anything matching the Request-URI.
XCAP Specific error cases
Result of operation results an a document that is not well-formed or valid (409)
Resource identified in a request corresponds to multiple elements or attributes (409)
Application usage not understood (409)
Document, element or attribute does not exist (404)
Client provided data that violates a uniqueness requirement (409)
Request did not contain valid xml-frag-body (409?)

55. Conveying Conflict Details
HTTP recommends including a 409 body detailing problem so client can retry
XCAP defines an XML body format for response
application/xcap-error+xml MIME type
Root element <xcap-error>
Child is specific to the error
Detailed error information can be dependent on the error
Defined errors match ones on previous slide

56. URI Exists Error
Client attempts to set a URI with a uniqueness constraint, and the value exists already
Happens in resource lists
Server error response indicates
URI(s) which had this problem
Optional suggested alternates
<?xml version="1.0" encoding="UTF-8"?>
<xcap-error
xmlns="urn:ietf:params:xml:ns:xcap-error">
<uri-exists>
<exists
</exists>
</uri-exists>
</xcap-error>

57. Handling Multiple Writers
Synchronization problems occur when multiple clients can manipulate the same document
Especially true when a client needs to do multiple HTTP operations to affect a change
XCAP provides no lock
But we want to detect this condition and recover
Common problem
User A
User B
XCAP Server
(1) PUT (Modify Buddy 1)
(2) 200 OK
(3) PUT (Modify Buddy 1)
(4) 200 OK
B wins
(5) DELETE (attribute removed by A)
(6) 409

58. Solution: Etags ETag from HTTP What does this mean?
Entity tags are used for comparing two or more entities from the same requested resource.
An entity tag MUST be unique across all versions of all entities associated with a particular resource.
What does this mean?
ETag is a version identifier for a resource
Server assigns the etag
It changes every time the resource changes

59. How are they used? HTTP defines several conditional headers
If-Match: only process this request if the entity tag matches that held by the server
If-None-Match: only process this request if the entity tag does not match
If-Range: asks for the byte range that has changed
Server returns 412 if condition fails

60. Example Revisited User A has version ABC
Adds buddy, adds If-Match: ABC
Buddy added, new version DEF
User B also has version ABC
Tries to modify it, but it fails
B can now fetch it and make its diff against the current version
User A
User B
XCAP Server
(1) PUT (Modify Buddy 1) Etag ABC
(2) 200 OK Etag DEF
(3) PUT (Modify Buddy 1) ABC
(4) 412

61. Data Extensibility
XCAP servers MUST understand the application usages they manage
They don’t need to understand any namespaces but the root ones
Document extensions don’t need to be understood
Sometimes, an extension requires the server to understand
Setting a URI
Guaranteeing Uniqueness

62. Current Solution Defines a “mandatory-ns” element
This attribute is present as a child of the root element in any document
Indicates what namespaces are mandatory
<?xml version="1.0" encoding="UTF-8"?>
<address-book xmlns:conf=“urn:ietf:2233”>
<mandatory-ns>
<ns>urn:ietf:2233</ns>
</mandatory-ns>
<!—This guy is a bozo -->
<entry>
<name>Jonathan Rosenberg</name>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<conference-uri/>
<ietf-participant/>
</entry>
</address-book>

63. Presence Authorization
Specified as a ruleset
Each ruleset is a series of rules
Each rule has three parts
Condition – does this rule apply?
Action – what do you do if it does?
Transformation – how do you restrict the data seen by a requestor?

64. Permission Model Each action or transformation is called a permission
A permission is a positive grant of information
There can never be negative grants, i.e., “don’t send information X”
If there is no permission for something, you get nothing
Implication is that the system is privacy safe

65. Privacy Safe
If a server doesn’t understand a permission, less information is sent than desired, never more
If a server cannot obtain a rule from a remote source, less information is sent than desired, never more
No network failures or other transient problems can result in more information being sent than is desired

66. Common Policy draft-ietf-geopriv-common-policy Defines framework
Defines common elements in all systems
<identity> - condition matching based on user identity
<sphere> - condition based on your presence status
<validity> - time range

67. Current Presence Authorization Elements
Extends the set defined in common-policy with presence-specific data
New conditions
<anonymous> - is the subscription anonymous
Actions
<accept-subscription> - accept the presence subscription
<provide-presence> - polite blocking or not
Transformations
<show-namespace> - provide elements from a specific namespace
<show-tuple> - provide elements from specified tuples
<show-element> - provide elements with a specific name

68. <?xml version="1.0" encoding="UTF-8"?>
<cr:ruleset xmlns="urn:ietf:params:xml:ns:pres-rules"
xmlns:cr="urn:ietf:params:xml:ns:common-policy"
xmlns:rpid="urn:ietf:params:xml:ns:rpid"
xmlns:xsi="
<cr:rule id="1">
<cr:conditions>
<cr:identity>
</cr:identity>
</cr:conditions>
<cr:actions>
<accept-subscription>true</accept-subscription>
<provide-presence>true</provide-presence>
</cr:actions>
<cr:transformations>
<show-namespace>
<ns>urn:ietf:params:xml:ns:rpid</ns>
</show-namespace>
<show-element>
<basic-elements/>
<el>rpid:placetype</el>
</show-element>
</cr:transformations>
</cr:rule>
</cr:ruleset>