§ Access configuration documents on server: like Presence Server, XDM Server
§ Maps XML documents and document components into HTTP URIs
§ HTTP primitives can be used to directly manipulate the data
1). XCAP Overview
§ The XML Configuration Access Protocol (XCAP), is an application layer protocol that allows a client to read, write, and modify application configuration data stored in XML format on a server.
§ Normal HTTP primitives can be used to manipulate the data
§ 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.
§ 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.
§ XCAP uses the HTTP methods PUT, GET, and DELETE to operating on XML documents stored in the server.
2). XCAP Roles: XCAP Client, XCAP Server and Authentication Proxy
§ XCAP defines two logical roles: XCAP client and XCAP servers.
§ In 3GPP [24.423] & [24.623], an XCAP client is an HTTP/1.1 compliant client. Similarly an XCAP server is an HTTP/1.1 compliant server.
§ The XCAP server acts as a repository of XML documents that customize and modify the execution of NGN PSTN/ISDN simulation services.
§ Authentication of the user with HTTP may take place (1) directly at the AS or with the (2) support of an Authentication Proxy
§ An Authentication Proxy is an HTTP/1.1 compliant server whose main purpose is to authenticate the user requests. The Authentication Proxy is used to separate the authentication procedure and the Application Server (AS) specific application logic to different logical entities.
§ The AP is configured as a HTTP reverse proxy, i.e. the FQDN of the AS is configured to the AP such a way that the IP traffic intended to the AS is directed to the AP by the network. The AP performs the authentication of the UE. After the authentication procedure has been successfully completed, the AP assumes the typical role of a reverse proxy, i.e. the AP forwards HTTP requests originating from the UE to the correct AS, and returns the corresponding HTTP responses from the AS to the originating UE.
3). Application Usages:
§ Each application that makes use of XCAP defines its own XCAP application usage.
§ Define how the XCAP server can manipulate corresponding application documents
§ Key components: AUID, XML Schema, data validation, data interdependency, authorization policies
§ 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
3-1). Application Unique ID:
§ Unique Identifier for each application
§ Want this to be global
§ Pick an appropriate AUID, e.g., address-book
§ Add an IANA Considerations section registering the AUID
Application AUID provided by XCAP
The following applications are provided by XCAP, by using specific AUID (Application Unique Id):
§ XCAP capabilities (AUID = xcap-caps).
§ Resource lists (AUID = resource-lists). A resource lists application is any application that needs access to a list of resources, identified by a URI, to which operations, such as subscriptions, can be applied.
§ Presence rules (AUID = pres-rules, org.openmobilealliance.pres-rules). A Presence Rules application is an application which uses authorization policies, also known as authorization rules, to specify what presence information can be given to which watchers, and when.
§ RLS services (AUID = rls-services). A Resource List Server (RLS) services application is Session Initiation Protocol (SIP) application whereby a server receives SIP SUBSCRIBE requests for resource, and generates subscriptions towards the resource list.
§ PIDF manipulation (AUID = pidf-manipulation). Pidf-manipulation application usage defines how XCAP is used to manipulate the contents of PIDF based presence documents.
§ Watchers (AUID = watchers, proprietary application).
3-2). Two sub-namespaces
§ 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.
§ It also defines a default namespace that applies to elements in the URI without namespace prefixes.
A). IETF tree: tokens in RFC documents
§ IANA Registry
§ Example: “resource-lists”, “pidf-manipulation”, “pres-rules”
§ “resource-lists” draft-ietf-simple-xcap-list-usage
§ “pidf-manipulation” draft-isomaki-simple-xcap-pidf-manipulation-usage-00
§ “rules” draft-rosenberg-simple-rules
B). Vendor tree: proprietary data
§ Start with reverse DNS name of enterprise
§ prefixed with the reverse domain name of the organization
§ meant to be used in lab environments where no central registry is needed
§ Example: “com.example.customer-list”
3-3). Data Validation
§ Uniqueness constraints, referential integrity
§ 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.
§ This is done using two mechanisms. Firstly, all application usages MUST describe their document contents using XML schema
3-4). Data Semantics
§ An address book is a series of
3-5). 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
3-6). Data interdependency
§ Operation of one element may affect other elements; especially cross-document affection
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
3-7). Authentication:
§ Authentication of the user with HTTP may take place (1) directly at the AS or with the (2) support of an Authentication Proxy
3-8). 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
§ A user can only read global data
§ Global data is readable by everyone, writeable by no one except privileged users
Specified as a ruleset like Presence Authorization
§ 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?
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
§ 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
Defines common elements in all systems
§
§
§
Presence Authorization Elements
Extends the set defined in common-policy with presence-specific data
New conditions
§
Actions
§
§
Transformations
§
§
§
3-9). 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
4). URI Construction:
XCAP defines URIs as two parts
§ Document selector – chooses the XML document
§ Node selector – chooses the XML component (element, attribute)
§ Example: XCAP root / Document Selector / Node Selector
XCAP root
§ Context in which all other resources exist
§
Document Selector
§
Node Selector
§ ~~/resource-lists/list%5b@name=%
4-1). XPath = XML Addressing
§ How to point to specific pieces of an XML document
§ The XCAP addressing mechanism is based on XPath, that provides the ability to navigate around the XML tree.
4-2). Document Hierarchy
http://docs.google.com/View?id=ddh56dhg_285g4836tgk
XML documents organized into a mandatory hierarchy
- Borrows from ACAP concepts
§ This application usage defines the XML schema for the data used by the application, along with other key pieces of information.
§ XCAP focuses on the definition of XML documents that are compliant with the XML schema and constrains defined for a particular XCAP application usage.
§ XCAP allows application to provide XML documents that are common for all users or XML documents that affect the service of a given user.
§ Central to XCAP is the construction of the HTTP URI that points to particular XML document or certain components of it.
§ A component in an XML document can be an XML element, attribute, or the value of it.
§ to structure, store, and transport information
§ everything from (including) the element's start tag to (including) the element's end tag.
§ specified in XML elements’ tags;
§ provide additional information about elements.
4-3). XML Schema
§ IANA registry for schema and namespace
§ Need a way to define the constraints on an XML document
Ø Analogous to a database schema
Ø Similar to a grammar
§ W
Ø DTD (Document Type Definition)
Ø Schema (à Trend is towards this Schema)
§ XML Schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by XML itself.
§ These constraints are generally expressed using some combination of
Ø Grammatical rules governing the order of elements,
Ø Boolean predicates that the content must satisfy,
Ø Data types governing the content of elements and attributes, and
Ø More specialized rules such as uniqueness and referential integrity constraints.
5). XCAP Operations
§ The following operations are supported via XCAP protocol in a client-server interaction:
Ø Retrieve an item
Ø Delete an item
Ø Modify an item
Ø Add an item
§ The operations above can be executed on the following items:
Ø Document
Ø Element
Ø Attribute
§ When the XCAP server receives an HTTP PUT, HTTP GET or HTTP DELETE request for manipulating or fetching a resource list, the XCAP server shall first authenticate the request and then perform authorization
§ KEY CONSTRAINT: can only affect one element, attribute or document at a time
5-1). HTTP PUT
§ Create or Replace a Document/Element/Attribute
§ Adding: Document, Element, Attribute
§ Modifying: Document, Element, Attribute
5-2). HTTP DELETE
§ Delete a Document/Element/Attribute
§ Deleting: Document, Element, Attribute
5-3). HTTP GET
§ Fetch a Document/Element/Attribute
§ Retrieving: Document, Element, Attribute
6). Server error handling is specified in HTTP specification
6-1). 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.
6-2). 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)
6-3). Conflicts occur with simultaneous multiple modifications
§ Use etag: A version control
§ When one resource changes, all resources in the same documents get the same new etag
§ Client: contain previously known etag in the If-Match header field of request
§ Server: return new etag in response on success
§ Example: Synchronization problems occur when multiple clients can manipulate the same document
http://docs.google.com/View?id=ddh56dhg_281gj72nbgp
http://docs.google.com/View?id=ddh56dhg_283c7vmv8cf
7). Security Considerations and Solution:
§ Using HTTP port: 80 – Hard to apply port-based filtering
§ Connection over TLS
§ HTTP Digest Authentication
§ URL-analysis-based traffic filtering: The presence of the double tilde (~~) is a strong hint that the URL points to an XML element or attribute
§ Authorization policies in Application Usage
8). Signalling Flow and Example of Operation: N/A
9-1). Definition of XCAP [24.423] & [24.623] in 3GPP
§ Application Unique ID (AUID): Each XCAP application usage is associated with a unique name called the Application Unique ID (AUID). The AUID defined by this application usage falls into the vendor‑proprietary namespace of XCAP AUID, where ETSI is considered a vendor.
§ The AUID allocated to the NGN PSTN/ISDN simulation services XCAP application usage is: simservs.ngn.etsi.org
§ Default namespace: XCAP requires application usages to declare the default namespace. The default namespace of the NGN PSTN/ISDN simulation services XCAP application usage is: http://uri.etsi.org/ngn/params/xml/simservs/xcap
§ MIME type: The MIME type of NGN PSTN/ISDN simulation services XML documents is: application/simservs+xml
§ Validation constraints: The present document does not specify any additional constraint beyond those defined by XCAP. Note, however, that each of the supplementary services may specify additional constraints on each of the XML subdocuments.
§ Data semantics: The XML schema does not accept URIs that could be expressed as a relative URI reference causing a resolution problem. However, each of the supplementary services should consider if relative URIs are allowed in the subdocument tree, and in that case, they should indicate how to resolve relative URI references. In the absence of further indications, relative URI references should be resolved using the document URI as the base of the relative URI reference.
§ Naming conventions: By default, NGN PSTN/ISDN simulation services XML documents are stored under the user's Home Directory (which is located under the
§ Resource interdependencies: The present document does not specify additional resource interdependency beyond those specified in the XML schema and beyond any resource interdependency that may be specified in each of the NGN PSTN/ISDN simulation services.
§ Authorization policies: The default XCAP authorization policy is used in the application usage defined by the present document.
§ XML Schema: The XML schema for the simservs XML document, including the common parts. This XML schema allows for each of the individual XML schemas pertaining to a particular service to import the common parts XML schema. Each XML fragment affects the settings of a supplementary service (or group of services). The XML schema of each of the supplementary services is specified in its own specification. A template of the XML schema for a supplementary service is provided.
9-2). Standard and Reference:
The XCAP protocol is based on the following IETF standards:
§ RFC4825 – XML Configuration Access Protocol (XCAP)
§ RFC4826 – XML Formats for Representing Resource Lists
§ RFC4827 – XCAP Usage for Manipulating Presence Document Contents
§ RFC5025 – Presence Authorization Rules
