Xcap

43
XCAP (The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) ) Date: 26-09-2011 [email protected] by: Saurabh Sharma Mob: +91 931 115 3370

Transcript of Xcap

XCAP(The Extensible Markup Language (XML)

Configuration Access Protocol (XCAP) )

Date: 26-09-2011

[email protected]

by: Saurabh Sharma

Mob: +91 931 115 3370

Confidential Slide

Agenda of Today

RFC 4825

• Introduction to XCAP

• Overview of Operations and Definitions

• URI Construction ,Client Operations, Server Behavior

• XCAP Server Capability

RFC 4662

• Introduction to SIP Event Notification Extension for Resource Lists

• Overview of Operations and Definitions

• List Subscription

• RLS Processing of SUBSCRIBE Requests

• RLS Generation of NOTIFY Requests

• Subscriber Processing of NOTIFY Requests

2

Confidential Slide

Time Line

RFC 4825

• The Extensible Markup Language (XML) 1.5 hours Configuration Access Protocol (XCAP)

RFC 4662

• Introduction to SIP Event Notification 30 minutes Extension for Resource Lists

3

Confidential Slide

Response

This is a session for level setting

People are at different points

We will start from beginning

You are free to ask any question in between .

Please interrupt and ask.

4

Confidential Slide

Objective

To understand, ”What is XCAP”

To find ”Need of XCAP.”

Working of XCAP

How XCAP can be integrated with current setup

5

Confidential Slide

Need of XCAP

In many cases, a subscriber has a list of resources they are

interested in. Without some aggregating mechanism, this will

require the subscriber to generate a SUBSCRIBE request for

each resource about which they want information.

For environments in which bandwidth is limited, such as

wireless networks, subscribing to each resource individually

is problematic. UserA TeSserver User B

(logged in)

REGISTER200 OK

SUBSCRIBE (ForB)

SUBSCRIBE (ForB)200 OK

200 OK

NOTIFY200 OKNOTIFY

200 OK

User C

(logged in)

SUBSCRIBE (For C)

SUBSCRIBE (For C)200 OK

200 OKNOTIFYNOTIFY

200 OK 200 OK

6

Confidential Slide

Solution

Requesting and conveying notifications for lists of resources.

A resource list is identified by a URI, and it represents a list of

zero or more URIs. Each of these URIs is an identifier for an

individual resource for which the subscriber wants to receive

information.

The notifier for the list is called a "resource list server", or

RLS. In order to determine the state of the entire list, the RLS

will act as if it has generated a subscription to each resource

in the list.

Client RLS

Subscribe

Notify

List

List

7

Confidential Slide

Definitions

XCAP Resource, Server and Client.

Application, Application Usage and Application Unique ID (AUID)

XCAP User Identifier (XUI)

XCAP Root, Document Selector

Node Selector and Node Selector Separator

Document URI and Node URI

List Subscription

Back-End Subscription and Virtual Subscription

Resource, Resource List and Resource List Server(RLS)

8

Confidential Slide

Introduction to XCAP

An Application Layer Protocol

Allows a client to

read,

write, and

modify

Application configuration data stored in XML format on a

server.

XCAP maps XML document sub-trees and element attributes

to HTTP URIs, so that these components can be directly

accessed by clients using HTTP protocol.

9

Confidential Slide

Introduction to XCAP (continued)

An XCAP server is used by XCAP clients to store data like

buddy lists and presence policy in combination with a SIP

Presence server that supports PUBLISH, SUBSCRIBE and

NOTIFY methods to provide a complete SIP SIMPLE server

solution.

10

Confidential Slide

Application Usage

It is the detailed information on the interaction of an

application with the XCAP server.

Defines what an application needs to do to be used with

XCAP

Each XCAP resource on a server is associated with an application. In

order for an application to use those resources, application specific

conventions must be specified.

Those conventions include the XML schema that defines the structure

and constraints of the data, well known URIs to bootstrap access to

the data, and so on.

All of those application specific conventions are defined by the

application usage.

11

Confidential Slide

Application Usage(continued)

Application Usage need to

Define an Application Unique ID

Default Document Namespace.

Define data semantics

Data Validation.

Specify naming conventions – binding between application and XCAP

Data interdependencies

Authorization policies

12

Confidential Slide

Application Unique ID

This name uniquely identifies the application usage within the

namespace of application usages, and is different from AUIDs

used by other applications.

Each AUID in that namespace is prefixed with the reverse

domain name of the organization creating the AUID, followed

by a period, followed by any vendor defined token.

Example 1:

the example.com domain can create an AUID with the value

"com.example.foo"

13

Confidential Slide

Application Unique ID(continued)

Syntax for AUIDs, expressed in ABNF

AUID = global-a-uid / vendor-a-uid

global-a-uid = a-uid

a-uid = 1*a-uid-char

vendor-a-uid = rev-hostname "." a-uid

rev-hostname = toplabel *( "." domainlabel )

domainlabel = alphanum/ alphanum *( alphanum / "-" ) alphanum

toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum

a-uid-char = a-uid-unreserved / pct-encoded / sub-delims / ":" / "@";

pct-encodefrom RFC 3986;sub-delims from RFC 3986

alphanum = ALPHA/DIGIT;DIGIT from RFC 4234;ALPHA from RFC4234

a-uid-unreserved = ALPHA / DIGIT / "-" / "_" / "˜"

14

Confidential Slide

Default Document Namespace

In order for the XCAP server to match a URI to an element or

attribute of a document, any XML namespace prefixes used

within the URI must be expanded.

This expansion requires a namespace binding context. That

context maps namespace prefixes to namespace URIs.

The namespace binding context comes from two sources.

By URI itself.

By Application Usage.

XML Namespace

PrefixNamespace URI

Mapping

Expansion

Requires Namespace Binding Context

15

Confidential Slide

Data Validation

One of the responsibilities of an XCAP server is to validate

the content of each XCAP resource when an XCAP client

tries to modify one.

Uniqueness constraints

– In many cases, an application will require that there be only one instance

of some element or attribute within a particular scope.

– For example, the resource lists application usage requires that each <list>

element have a unique value for the "name" attribute within a single

parent. As another example, the RLS services application usage requires

that the value of the "uri" attribute of the <service> element be a URI that

is unique within the domain of the URI.

16

Confidential Slide

Data Validation(continued)

Referential integrity

– Referential integrity is important when the name or value of an element or

attribute is used as a key to select another element or attribute.

– XCAP clients are responsible for making all the appropriate changes to

documents in order to maintain referential integrity.

Character encoding

– XCAP specification mandates that all documents used with XCAP MUST

be encoded using UTF-8

17

Confidential Slide

Naming Conventions

Define well-known URIs used for bootstrapping purposes,

and any other conventions on the URIs used by an

application.

For many application usages, users need only a single document. In

such a case, it is RECOMMENDED that the application usage require

that this document be called "index" and exist within the user’s home

directory.

– Example 2: The RLS services application usage allows an RLS to obtain

the contents of a resource list when the RLS receives a SUBSCRIBE

request for a SIP URI identifying an RLS service. The application usage

specifies that the list of service definitions is present within a specific

document with a specific name within the global tree. This allows the RLS

to perform a single XCAP request to fetch the service definition for the

service associated with the SIPURI in a SUBSCRIBE request.

18

Confidential Slide

Resource Interdependencies

When a user modifies an XCAP resource, the content of

many other resources is affected.

Example 3: When a user deletes an XML element within a document,

it does so by issuing a DELETE request against the URI for the

element resource. However, deleting this element also deletes all

child elements and their attributes, each of which is also an XCAP

resource. As such, manipulation of one resource affects the state of

other resources.

Example 4: When a user creates a new RLS service (that is, it creates

a new <service> element within an RLS services document), the

server adds that element to a read-only global list of services

maintained by the server in the global tree. This read-only global List

is accessed by the RLS when processing a SIP SUBSCRIBE request.

Resource interdependencies are used by both XCAP clients and

servers.19

Confidential Slide

Authorization Policies

By default, each user is able to access (read, modify, and

delete) all the documents below their home directory, and

any user is able to read documents within the global

directory.

Only trusted users, explicitly provisioned into the server, can

modify global documents.

20

Confidential Slide

Hierarchy Structure

Top is the Root Services URI Identifies start of XCAP tree

– 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 called XUI (AOR in SIP)

XCAP defines URIs as two parts

Document selector – chooses the XML document

Node selector – chooses the XML component (element, attribute)

21

Confidential Slide

The Hierarchy

Root services

AUID 1 AUID 2

users global

petri hiroshi

doc1 dir1

22

Confidential Slide

URI Construction

In order to manipulate an XCAP resource, the data must be

represented by an HTTP URI.

The URI is constructed by concatenating the XCAP root with the

document selector with the node selector separator with a percent-

encoded form of the node selector.

This is followed by an optional query component that defines

namespace bindings used in evaluating the URI.

URIXCAP

RootDocument Selector Node Selector

Optional Query

23

Confidential Slide

XCAP Root

The XCAP root is the enclosing context in which all XCAP

resources exists.

Its purpose is to identify the root of the tree within the domain

where all XCAP documents are stored.

XCAP root URI is provisioned into client devices. If not

explicitly provisioned, clients SHOULD assume the form

xcap.domain, where domain is the domain of their service

provider (for SIP, this would be the domain part of their

Address-of-Record (AOR)).

Example 4:

"http://xcap.example.com" might be used as the XCAP root URI within

the example.com domain.

24

Confidential Slide

Document Selector

Each document within the XCAP root is identified by its

document selector, contains sequence of path segments

separated by a slash ("/").

The first path segment MUST be the XCAP AUID.

Beneath each AUID, there are two sub-trees.

users - Holds the documents that are applicable to specific users.

global - Holds documents applicable to all users.

The sub-tree beneath "global" is called the global tree. The

path segment after the AUID must either be "global" or

"users".

25

Confidential Slide

Document Selector (continued)

The final path segment in the document selector identifies the

actual document in the hierarchy.

Example 5:

The path segment "/resource-lists/users/sip:[email protected]/index"

is a document selector. Concatenating the XCAP root URI with the

document selector produces the HTTP URI

"http://xcap.example.com/resource-lists/users

/sip:[email protected]/index".

In this URI, the AUID is "resource-lists", and the document is in the

user tree with the XUI "sip:[email protected]" with filename "index".

26

Confidential Slide

Node Selector

Specifies specific nodes of the XML document that are to be

accessed. The nodes refers to:

XML element.

An attribute of element.

Set of namespace bindings.

To determine the XML element, attribute, or namespace

bindings selected by the node selector, processing begins at

the root node of the XML document.

Selection of an element is done by its name (expanded), by a

combination of name and attribute value, by name and

position, or by name, position and attribute.

27

Confidential Slide

Node Selector(continued)

Example 6: The node selector watcherinfo/watcher-list/watcher[@id="8ajksjda7s"] <?xml version="1.0"?>

<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo“ version="0" state="full">

<watcher-list resource="sip:[email protected]"

package="presence">

<watcher status="active"

Id="8ajksjda7s"

duration-subscribed="509"

event="approved">sip:[email protected]</watcher>

<watcher status="pending"

id="hh8juja87s997-ass7"

display-name="Mr. Subscriber"

event="subscribe">sip:[email protected]</watcher>

</watcher-list>

</watcherinfo>

Answer: <watcher status="active"

id="8ajksjda7s"

duration-subscribed="509"

event="approved">sip:[email protected]</watcher>

28

Confidential Slide

Node Selection Process Algorithm

Within the current document context, the children of that

context are enumerated in document order.

If the context is the root node of the document, its child element is the

root element of the document.

If the context is an element, its children are all of the children of that

element.

Next, those elements whose name is not a match for

NameorAny are discarded.

If an element name is a match then there are two cases:

– if NameorAny is the wildcard.

– if it is not a wildcard.

29

Confidential Slide

Node Selection Process Algorithm(continued)

Matching is as follows (result of previous computation will be

stored in ordered list of Elements)

The elements in the list are further filtered by the predicates( “ [ ]“).

Each predicate further prunes the elements from the current ordered

list and evaluate the order.

The content of predicate is of two types:

– position

– att-name att-value

If the content of the predicate is a position, the position-th element is

selected (that is, treat "position" as a variable, and take the element

whose position equals that variable), and all others are discarded.

– If beyond the list return result no match.

30

Confidential Slide

Node Selection Process Algorithm(continued)

If the content of the predicate is an attribute name and value, all

elements possessing an attribute with that name and value are

selected, and all others are discarded.

– If No result.

• Return no-match with reason Node Selector Invalid

– If One result.

• Return result with reason Node Selector valid.

• This element become the context for evaluation of next step in the node

selector expression.

– If Multiple result.

• Return result invalid with reason Node Selector Invalid.

31

Confidential Slide

Node Selection Process Algorithm(continued)

As a result, ones the entire node selector is evaluated

against the document, the result will be

No – match

Invalid

Single element

Single attribute.

32

Confidential Slide

Client Operations

Modifying

Document

Element

Attribute

Retrieving

Document

Element

Attribute

Deleting

Document

Element

Attribute

Adding

Document

Element

Attribute

33

Confidential Slide

Retrieving a Document

Example 7:

GET http://xcap.example.com/addressbook/users/petri/adbook1

HTTP/1.1

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

<address-book>

<!—This guy is a bozo --

<entry>

<name>Jonathan Rosenberg</name>

<email>[email protected]</email>

<postal>

<street paved=“true”>600 Lanidex Pl</street>

<city>Parsippany</city>

<state>NJ</state>

<country>USA</country>

</postal>

<ietf-participant/>

</entry>

</address-book>

adbook1

HTTP/1.1 200 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>

<email>[email protected]</email>

<postal>

<street paved=“true”>600 Lanidex Pl</street>

<city>Parsippany</city>

<state>NJ</state>

<country>USA</country>

</postal>

<ietf-participant/>

</entry>

</address-book>

34

Confidential Slide

Retrieving an Element

Example 8:

GET

http://xcap.example.com/addressbook/users/petri/adbook1/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>

<email>[email protected]</email>

<postal>

<street paved=“true”>600 Lanidex Pl</street>

<city>Parsippany</city>

<state>NJ</state>

<country>USA</country>

</postal>

<ietf-participant/>

</entry>

</address-book>

adbook1

HTTP/1.1 200 OK

Content-Type: application/xml-fragment-body

Content-Length: …

<name>Jonathan Rosenberg</name>

35

Confidential Slide

Retrieving an Attribute

Example 9:

GET

http://xcap.example.com/addressbook/users/petri/adbook1/address-

book/entry/street/@paved HTTP/1.1

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

<address-book>

<!—This guy is a bozo --

<entry>

<name>Jonathan Rosenberg</name>

<email>[email protected]</email>

<postal>

<street paved=“true”>600 Lanidex Pl</street>

<city>Parsippany</city>

<state>NJ</state>

<country>USA</country>

</postal>

<ietf-participant/>

</entry>

</address-book>

adbook1

HTTP/1.1 200 OK

Content-Type: application/xml-attribute-value

Content-Length: …

true

36

Confidential Slide

Delete a Document

Example 10:

DELETE http://xcap.example.com/addressbook/users/petri/adbook1

HTTP/1.1

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

<address-book>

<!—This guy is a bozo --

<entry>

<name>Jonathan Rosenberg</name>

<email>[email protected]</email>

<postal>

<street paved=“true”>600 Lanidex Pl</street>

<city>Parsippany</city>

<state>NJ</state>

<country>USA</country>

</postal>

<ietf-participant/>

</entry>

</address-book>

adbook1

HTTP/1.1 200 OK

37

Confidential Slide

Delete an Element

Example 11:

DELETE

http://xcap.example.com/addressbook/users/petri/adbook1/address-

book/entry/name/email HTTP/1.1

Before After

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

<address-book>

<!—This guy is a bozo --

<entry>

<name>Jonathan Rosenberg</name>

<email>[email protected]</email>

<postal>

<street paved=“true”>600 Lanidex Pl</street>

<city>Parsippany</city>

<state>NJ</state>

<country>USA</country>

</postal>

<ietf-participant/>

</entry>

</address-book>

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/1.1 200 OK

38

Confidential Slide

Server Behavior

XCAP server is an HTTP/1.1 compliant origin server.

When the server receives a request, the treatment depends

on the URI. If the URI refers to an application usage not

understood by the server, the server MUST reject the request

with a 404 (Not Found) response.

Next, the server authenticates the request.

Next, the server determines if the client has authorization to

perform the requested operation on the resource.

Next, the server makes sure that it can properly evaluate the

request URI.

39

Confidential Slide

SIP-specific event notification mechanism

It allows a user (the subscriber) to request to be notified of

changes in the state of a particular resource.

This is accomplished by the subscriber generating a

SUBSCRIBE request for the resource, which is processed by

a notifier that represents the resource.

The notifier for the list is called a "resource list server", or

RLS.

A resource list is identified by a URI, and it represents a list of

zero or more URIs.

Each of these URIs is an identifier for an individual resource

for which the subscriber wants to receive information.

40

Confidential Slide

References

Request for Comments: 4662

A Session Initiation Protocol (SIP) Event Notification Extension for

Resource Lists

Author : A. B. Roach , B. Campbell - Estacado Systems August 2006

J. Rosenberg - Cisco Systems August 2006

Request for Comments: 4825

The Extensible Markup Language (XML)Configuration Access

Protocol (XCAP)

Author : J. Rosenberg - Cisco Systems May 2007

41

Confidential Slide

Queries

Queries

Queries

Queries

42

Confidential Slide 43