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 • XCAP Basics
– Basic XML Concepts
– Namespaces
– Schema
– XPath in Brief
• HTTP Concepts of
Note
– Etags
• XCAP Problem
Definition
4. XML Basics
• XML is a mechanism for <?xml version="1.0" encoding="UTF-8"?>
representing structured <address-book>
<!—This guy is a bozo --
data <entry>
• Data is represented by a <name>Jonathan Rosenberg</name>
<email>jdrosen@dynamicsoft.com</email>
tree <postal>
<street paved=“true”>600 Lanidex Pl</street>
• Each node in the tree is <city>Parsippany</city>
an element <state>NJ</state>
<country>USA</country>
• Elements have attributes </postal>
<ietf-participant/>
– Attributes qualify the data
</entry>
• “Leaf” Elements can </address-book>
contain text content
5. XML Basics
• XML Comments <?xml version="1.0" encoding="UTF-8"?>
<address-book>
• Elements can be <!—This guy is a bozo --
empty <entry>
<name>Jonathan Rosenberg</name>
– <el-name/> shorthand <email>jdrosen@dynamicsoft.com</email>
<postal>
• XML Declaration <street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
– Version <state>NJ</state>
<country>USA</country>
– Encoding </postal>
<ietf-participant/>
• IETF uses UTF-8 </entry>
</address-book>
6. XML Terms
• Well-formed
– 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
<?xml version="1.0" encoding="UTF-8"?>
– Want to combine content <address-book>
from different systems into <!—This guy is a bozo --
one document <entry>
– What if both sources define <name>Jonathan Rosenberg</name>
<email>jdrosen@dynamicsoft.com</email>
the same name? <postal>
• Example <street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
– Add information to address <state>NJ</state>
book on whether data is <country>USA</country>
synced with PC </postal>
– <state>synchronized</stat <ietf-participant/>
e> </entry>
</address-book>
– Which state is it?
8. XML Namespaces
<?xml version="1.0" encoding="UTF-8"?
• Solution: XML xmlns:post=“http://www.post.com”
Namespace xmlns:sync=“http://www.sync.com”>
• Elements and attributes <post:address-book>
are bound to a <!—This guy is a bozo --
namespace when defined <post:entry>
<post:name>Jonathan Rosenberg</post:name>
• Namespace is identified <post:email>jdrosen@dynamicsoft.com</post:email>
with a unique URI <post:postal>
• A prefix is bound to that <post:street paved=“true”>600 Lanidex Pl</post:street>
<post:city>Parsippany</post:city>
URI through a declaration <post:state>NJ</post:state>
in the document <post:country>USA</post:country>
• Each element is named </post:postal>
with its qualified name <post:ietf-participant/>
– The prefix, followed by a <sync:state>synchronized</sync:state>
</entry>
colon, followed by the
</address-book>
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
12. XPath
• XCAP selection is based on XPath
– 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
<?xml version="1.0" encoding="UTF-8"?
• Want to point to xmlns:post=“http://www.post.com”
xmlns:sync=http://www.sync.com
the email element xmlns=“http://www.post.com”>
• XPath expression <address-book>
<!—This guy is a bozo --
address-book/entry/email <entry>
• Just like a unix <name>Jonathan R<name>
<email>jr@dsoft.com</email>
filesystem path <postal>
<street paved=“true”>600 Lx Pl</street>
• Each “directory” <city>Parsippany</city>
<state>NJ</state>
identifies an <country>USA</country>
</postal>
element name <ietf-participant/>
<sync:state>synchronized</sync:state>
</entry>
</address-book>
14. Positional Selectors
• What if there are multiple
elements with that name? <foo>
– Can supply predicates which <bar>Hello</bar>
select one of the matching <bar>There</bar>
ones </foo>
– 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]
15. Select by Attribute Name
• You can select <foo>
elements that have <bar attr=“1”>Hi</bar>
<bar attr=“2”>How</bar>
attributes with specific <bar stuff=“LOTR”>Are</bar>
</foo>
values
element[@name=“value”]
• foo/bar[@attr=“1”]
• foo/bar[@attr=“2”]
• foo/bar[@stuff=“LOTR”]
16. Selecting Elements
• The result of selecting • XPath allows
an element includes selecting multiple
– The element elements
– Its children – XCAP does not use
– Its attributes this feature
– Everything between
open bracket of open
element to close
bracket of close
element
17. Selecting Attributes
• An attribute is
selected by prefixing <foo>
<bar attr=“1”>Hi</bar>
its name with an “@” <bar attr=“2” bool=“y”>How</bar>
• foo/bar[1]/@attr <movie stuff=“LOTR”>Are</bar>
</foo>
• foo/bar[@attr=“2”]/
@bool
• foo/movie/@stuff
• The selected object is
JUST the value
– Different from elements
– Name would be redundant
18. XCAP Problem Space
• Motivating use cases
– Buddy Lists
– Authorization Policies
– Hard state presence data
19. Buddy List Use Case
Subscribe List
• Client wants to subscribe Subscribe Joe
Subscribe Bob
to a list of users Subscribe Mary
• Send SUBSCRIBE to Read
server using SIP event List
list extension
• Server retrieves list Write
List
associated with buddylist
URI Data
Manipulation
– Generates SUBSCRIBEs Server
to them
Standard Ifaces
• Client can manage that
list
– Add, remove, modify Client
entries
20. Authorization Use Case
Subscribe Petri
• User Hiroshi subscribes
to Petri
• No auth policy in place, Read
List
generates a winfo
NOTIFY to Petri
Write
• Petri needs to be able to List
set authorization decision
Data
for Hiroshi winfo
Manipulation
Server
• Want to be able to set
such policies outside of a Standard Ifaces
subscription as well
Client
21. Hard State Presence Management Subscribe Petri
• Hiroshi subscribes to
Petri Notify
– Petri has been offline for Read
weeks PIDF
• Server sends NOTIFY
with current presence Write
state PIDF
• Petri wants to control Data
default state when offline Manipulation
Server
• Set it to
<activity>vacation</activit Standard Ifaces
y>
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
Network App
• Same as previous
pictures
Not
• Scope limited to client to Standardized
XCAP server
• Access from Network App Not
could be XCAP Standardized
– Acts as a client
• There may be no network XCAP
Server
app
– XCAP server is repository
for client data 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
29. XCAP Scope
• Application Usages
– 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”
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
http://server.com/rules/users/<username> 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)
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
38. Document Contents
• AUID • Naming Conventions
– Want this to be global – No server app
– Pick an appropriate AUID – No naming conventions
• address-book • No data
– Add an IANA interdependencies
Considerations section
registering the AUID • Default authorization
• XML Schema policy
– Include it
– IANA registry for schema
and namespace
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 <email> element, which contains the
email 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
– Identifies start of XCAP tree
• http://server.example.com/xcap-root
• http://www.example.com/docs/xml/ietf/xcap/root
• 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
• http://xcap.example.com/address-
book/users/petri/adbook1/address-book/entry/name
adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<email>jdrosen@dynamicsoft.com</email>
<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 • Modifying
– Document – Document
– Element – Element
– Attribute – Attribute
• Deleting • Adding
– Document – Document
– Element – Element
– Attribute – Attribute
KEY CONSTRAINT
Can only affect one element, attribute
or document at a time
45. Fetching a Document
GET http://xcap.example.com/address-book/users/petri/adbook1 HTTP/1.1
adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<email>jdrosen@dynamicsoft.com</email>
HTTP/1.1 200 OK <postal>
Content-Type: application/adbook+xml <street paved=“true”>600 Lanidex Pl</street>
Content-Length: … <city>Parsippany</city>
<state>NJ</state>
<?xml version="1.0" encoding="UTF-8"?> <country>USA</country>
<address-book> </postal>
<!—This guy is a bozo -- <ietf-participant/>
<entry> </entry>
<name>Jonathan Rosenberg</name> </address-book>
<email>jdrosen@dynamicsoft.com</email>
<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 http://xcap.example.com/address-book/users/petri/adbook1/
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>
<email>jdrosen@dynamicsoft.com</email>
HTTP/1.1 200 OK <postal>
Content-Type: application/xml-fragment-body <street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
Content-Length: … <state>NJ</state>
<country>USA</country>
</postal>
<name>Jonathan Rosenberg</name> <ietf-participant/>
</entry>
</address-book>
47. Fetching an Attribute
GET http://xcap.example.com/address-book/users/petri/adbook1/
address-book/entry/street/@paved HTTP/1.1
adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<email>jdrosen@dynamicsoft.com</email>
HTTP/1.1 200 OK <postal>
Content-Type: application/xml-attribute-value <street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
Content-Length: … <state>NJ</state>
<country>USA</country>
</postal>
true <ietf-participant/>
</entry>
</address-book>
48. Delete a Document
DELETE http://xcap.example.com/address-book/users/petri/adbook1 HTTP/1.1
adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<email>jdrosen@dynamicsoft.com</email>
HTTP/1.1 200 OK <postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
NULL
49. Deleting an Element <?xml version="1.0" encoding="UTF-8"?>
adbook1
DELETE <address-book>
<!—This guy is a bozo --
http://xcap.example.com/address-book/users/petri/adbook1/
<entry>
<name>Jonathan Rosenberg</name>
address-book/entry/name/email HTTP/1.1 <email>jdrosen@dynamicsoft.com</email>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
HTTP/1.1 200 OK <!—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>
50. Deleting an Attribute <?xml version="1.0" encoding="UTF-8"?>
adbook1
DELETE <address-book>
<!—This guy is a bozo --
http://xcap.example.com/address-book/users/petri/adbook1/
<entry>
<name>Jonathan Rosenberg</name>
address-book/entry/name <email>jdrosen@dynamicsoft.com</email>
/postal/street/@paved HTTP/1.1 <postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
HTTP/1.1 200 OK <!—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>
51. Modify vs. Add
• Modify and Add look the same
– 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 --
PUT http://xcap.example.com/address- <entry>
book/users/petri/adbook1/ <name>Jonathan Rosenberg</name>
<email>jdrosen@dynamicsoft.com</email>
address-book/entry/phone HTTP/1.1 <postal>
Content-Type: application/xml-fragment-body <street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
<phone>+19739525000</phone> </postal>
<ietf-participant/>
</entry>
</address-book>
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan Rosenberg</name>
<phone>+19739525000</phone>
HTTP/1.1 200 OK <email>jdrosen@dynamicsoft.com</email>
<postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
53. Modify an Element adbook1
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
PUT http://xcap.example.com/address- <entry>
book/users/petri/adbook1/ <name>Jonathan Rosenberg</name>
<email>jdrosen@dynamicsoft.com</email>
address-book/entry/name HTTP/1.1 <postal>
Content-Type: application/xml-fragment-body <street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
<name>Jonathan D. Rosenberg</name> </postal>
<ietf-participant/>
</entry>
</address-book>
<?xml version="1.0" encoding="UTF-8"?>
<address-book>
<!—This guy is a bozo --
<entry>
<name>Jonathan D. Rosenberg</name>
<email>jdrosen@dynamicsoft.com</email>
HTTP/1.1 200 OK <postal>
<street paved=“true”>600 Lanidex Pl</street>
<city>Parsippany</city>
<state>NJ</state>
<country>USA</country>
</postal>
<ietf-participant/>
</entry>
</address-book>
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 <?xml version="1.0" encoding="UTF-8"?>
constraint, and the value <xcap-error
exists already xmlns="urn:ietf:params:xml:ns:xcap-error">
<uri-exists>
• Happens in resource lists <exists uri="sip:friends@example.com">
<alt-uri>sip:friends2@example.com</alt-uri>
• Server error response </exists>
indicates </uri-exists>
– URI(s) which had this </xcap-error>
problem
– Optional suggested
alternates
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
58. Solution: Etags
• ETag from HTTP • What does this
– Entity tags are used mean?
for comparing two or – ETag is a version
more entities from the identifier for a
same requested resource
resource. – Server assigns the
– An entity tag MUST be etag
unique across all – It changes every time
versions of all entities the resource changes
associated with a
particular resource.
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
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 <?xml version="1.0" encoding="UTF-8"?>
“mandatory-ns” <address-book xmlns:conf=“urn:ietf:2233”>
<mandatory-ns>
element <ns>urn:ietf:2233</ns>
• This attribute is </mandatory-ns>
<!—This guy is a bozo -->
present as a child of <entry>
<name>Jonathan Rosenberg</name>
the root element in <email>jdrosen@dynamicsoft.com</email>
any document <postal>
<street paved=“true”>600 Lanidex Pl</street>
• Indicates what <city>Parsippany</city>
<state>NJ</state>
namespaces are <country>USA</country>
mandatory </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
