XCAP Tutorial: Jonathan Rosenberg

XCAP Tutorial
Jonathan Rosenberg
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!
Agenda
• Understanding XML • XCAP Basics
– Basic XML Concepts
– Namespaces
– Schema
– XPath in Brief
• HTTP Concepts of
Note
– Etags
• XCAP Problem
Definition
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

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>
– Encoding </postal>
<ietf-participant/>
• IETF uses UTF-8 </entry>
</address-book>
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
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>
the same name? <postal>
• Example <street paved=“true”>600 Lanidex Pl</street>
– 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?
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
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
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
Schema Example
<xs:schema targetNamespace="http://www.post.com" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.post.com" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="address-book">
<xs:complexType>
<xs:sequence>
<xs:element name="entry" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="email" type="xs:string"/>
<xs:element name="postal">
<xs:complexType>
<xs:sequence>
<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>
<xs:element name="ietf-participant"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
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
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>
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>
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]
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”]
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
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
XCAP Problem Space
• Motivating use cases
– Buddy Lists
– Authorization Policies
– Hard state presence data
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 to Server
them
Standard Ifaces
• Client can manage that list
– Add, remove, modify entries
Client
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
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
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
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
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
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
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
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
Fetch a document
GET http://server.com/dir/foo HTTP/1.1 <foo>

<bar attr=“2” bool=“y”>How</bar>
<movie stuff=“LOTR”>Are</bar>
</foo>
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: …
<foo>
<bar attr=“2” bool=“y”>How</bar>
<movie stuff=“LOTR”>Are</bar>
</foo>
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
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
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”
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
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
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
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)
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
Definition Example
• Basic address book from before
• Would author an RFC structured as
follows
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
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
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
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
The Hierarchy
Root services
AUID 1 AUID 2
users global
petri hiroshi
doc1 dir1
Example 1
• http://xcap.example.com/address-
book/users/petri/adbook1/address-book/entry/name
adbook1
<address-book>
<entry>
<postal>
<state>NJ</state>
</postal>
<ietf-participant/>
</entry>
</address-book>
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
Fetching a Document
GET http://xcap.example.com/address-book/users/petri/adbook1 HTTP/1.1
adbook1
<address-book>
<entry>
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>
<postal>
<state>NJ</state>
</postal>
<ietf-participant/>
</entry>
</address-book>
Fetching an Element
GET http://xcap.example.com/address-book/users/petri/adbook1/
address-book/entry/name HTTP/1.1
adbook1
<address-book>
<entry>
Content-Type: application/xml-fragment-body <street paved=“true”>600 Lanidex Pl</street>
Content-Length: … <state>NJ</state>
</postal>
<name>Jonathan Rosenberg</name> <ietf-participant/>
</entry>
</address-book>
Fetching an Attribute
GET http://xcap.example.com/address-book/users/petri/adbook1/
address-book/entry/street/@paved HTTP/1.1
adbook1
<address-book>
<entry>
Content-Type: application/xml-attribute-value <street paved=“true”>600 Lanidex Pl</street>
Content-Length: … <state>NJ</state>
</postal>
true <ietf-participant/>
</entry>
</address-book>
Delete a Document
DELETE http://xcap.example.com/address-book/users/petri/adbook1 HTTP/1.1
adbook1
<address-book>
<entry>
<state>NJ</state>
</postal>
<ietf-participant/>
</entry>
</address-book>
NULL
Deleting an Element adbook1
DELETE <address-book>
http://xcap.example.com/address-book/user <entry>
s/petri/adbook1/ <name>Jonathan Rosenberg</name>
address-book/entry/name/email HTTP/1.1 <postal>
<state>NJ</state>
</postal>
<ietf-participant/>
</entry>
</address-book>

<address-book>
HTTP/1.1 200 OK <!—This guy is a bozo --
<entry>
<postal>
<state>NJ</state>
</postal>
<ietf-participant/>
</entry>
</address-book>
Deleting an Attribute adbook1
DELETE <address-book>
http://xcap.example.com/address-book/user <entry>
s/petri/adbook1/ <name>Jonathan Rosenberg</name>
address-book/entry/name <postal>
/postal/street/@paved HTTP/1.1 <street paved=“true”>600 Lanidex Pl</street>
<state>NJ</state>
</postal>
<ietf-participant/>
</entry>
</address-book>

<address-book>
HTTP/1.1 200 OK <!—This guy is a bozo --
<entry>
<postal>
<street>600 Lanidex Pl</street>
<state>NJ</state>
</postal>
<ietf-participant/>
</entry>
</address-book>
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
Insert an Element adbook1
<address-book>
PUT http://xcap.example.com/address- <entry>
book/users/petri/adbook1/ <name>Jonathan Rosenberg</name>
address-book/entry/phone HTTP/1.1 <postal>
<state>NJ</state>
<phone>+19739525000</phone> </postal>
<ietf-participant/>
</entry>
</address-book>

<address-book>
<entry>
<phone>+19739525000</phone>
HTTP/1.1 200 OK <email>jdrosen@dynamicsoft.com</email>
<postal>
<state>NJ</state>
</postal>
<ietf-participant/>
</entry>
</address-book>
Modify an Element adbook1
<address-book>
PUT http://xcap.example.com/address- <entry>
book/users/petri/adbook1/ <name>Jonathan Rosenberg</name>
address-book/entry/name HTTP/1.1 <postal>
<state>NJ</state>
<name>Jonathan D. Rosenberg</name> </postal>
<ietf-participant/>
</entry>
</address-book>

<address-book>
<entry>
<name>Jonathan D. Rosenberg</name>
<state>NJ</state>
</postal>
<ietf-participant/>
</entry>
</address-book>
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?)
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
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
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
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.
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
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
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
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>
the root element in <email>jdrosen@dynamicsoft.com</email>
any document <postal>
• Indicates what <city>Parsippany</city>
<state>NJ</state>
namespaces are <country>USA</country>
mandatory </postal>
<conference-uri/>
<ietf-participant/>
</entry>
</address-book>
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?
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
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
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
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
<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="http://www.w3.org/2001/XMLSchema-instance">
<cr:rule id="1">
<cr:conditions>
<cr:identity>
<cr:uri>user@example.com</cr:uri>
</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>

XCAP Tutorial: Jonathan Rosenberg

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

XCAP Tutorial: Jonathan Rosenberg

Uploaded by

Copyright:

Available Formats

XCAP Tutorial

contain text content

• Client wants to subscribe Subscribe Joe

• Send SUBSCRIBE to Read

• User Hiroshi subscribes

– Petri has been offline for Read

• Server sends NOTIFY

• Petri wants to control Data

• Pushing and pulling partial pieces of the data is essential

GET http://server.com/dir/foo HTTP/1.1 <foo>

AUID = global-auid / vendor-auid

<?xml version="1.0" encoding="UTF-8"?>

<?xml version="1.0" encoding="UTF-8"?>

<?xml version="1.0" encoding="UTF-8"?>

<?xml version="1.0" encoding="UTF-8"?>

You might also like