XCAP Server

Anurag Chakravarti
Computer Science Dept.
Columbia University
New York, NY 10027
USA
ac2491@columbia.edu

Abstract

The project implements a XCAP Server for managing information, manipulated by the SIP clients, and accessed by the SIP presence-agent while servicing a request. This task can be performed for network servers not specific to SIP and its application usages. Managing information includes read, write and delete operations on valid XML fragments defined by the application usages, to the granularity of xml attributes. Application usages defining instance of SIP buddy-lists and presence authorization policy, have been integrated and tested.
Adding on, XCAP Client is integrated into SIPc for both the application usages.

Introduction

XCAP stands for XML Configuration Access Protocol. It defines the term XCAP URI which, leverages HTTP [2] URIs to represent, create, access, modify and delete portions of XML document representing user information stored in a server. The path in the HTTP URI is treated either as the location of a XML document or a namespace aware XPATH directed path to locations in the XML document. Namespace prefix in the XCAP URI is bound to the namespace, by the query component of the HTTP URI. Following are the logical parts of the XCAP URI
  • XCAP root
  • Document selector
    • AUID (Application Usage Identifier)
    • "user"/"global"
    • XUI (XCAP User Identifier)
    • filename
  • Path selector
  • Node selector
  • Query
HTTP request combined with the XCAP URI semantics makes a very powerful tool to edit content in a pre-defined manner on a web server. For more information on the above terms please refer to the xcap-draft[1]. For example SIP presence framework requires
  • presentities to store their presence authorization policies for different watchers. Thus making the policies accessible by the presence agent. The presence agent uses this information to compose presence rules to apply as filters on the notifications generated per subscribed watcher
  • presentites to store their buddy list information in a server for persistence
This can be conveniently achieved through the XML Configuration Access Protocol

Scope

  • The scope of the project defines implementation of XCAP Server as per the specification given by IETF draft draft-ietf-simple-xcap-08 [1].
  • Presence authorization rule; XCAP application usage has been incorporated in to the XCAP Server. This usage is implemented as per the specifications given in the IETF draft, draft-ietf-simple-presence-rules-04 [3]
    Buddy lists; XCAP application usage has been incorporated in to the XCAP Server. This usage is implemented as per the specifications given in the draft, draft-ietf-simple-xcap-list-usage-05 [4] Support for integrating this with Columbia's Presence Agent has been provided.
  • The XCAP Server as per the specification is not restricted to the SIP framework. It can support other application usages completely orthogonal to the SIP framework. It is important to realize that XCAP is a generic protocol with application usages currently written for storing SIP presence specific information.
  • SIPc [5], a user-agent developed by Columbia University has been integrated to make use of the XCAP Server for both the above mentioned use-cases. The UI screens of the SIP client is being worked upon with help from Xiaotao [6]
  • Unit and integration sunny and rainy day test cases in the form of C++ XCAP Client have been implemented. In the process a fairly independent C++ XCAP Client library was developed which is capable of sending XCAP requests and receiving XCAP updates from the server specifying the document changed. This is a nice tool for testing the XCAP server functionalities with any implementation of XCAP.
  • Work was considered in reviving the multiple XCAP URI draft with Kodiak networks [7], but substantial use cases have not been identified. Possible use cases could be:
    • Retrieve all XCAP documents in the domain managed by the Presence Agent for a particular application usage once the Presence Agent starts up
    • Any changes made in the SIP client (SIPc) while it is offline can be cached and applied once the SIP client comes online

Related Work

Previously developed XCAP Server based on the earlier specification [8]. However
  • Rework on the draft has been done since and is currently in a relatively more mature state.
  • The earlier implementation being a monolithic block of code does not scale well
The server hence developed, has been re-designed but reuses pieces of the existing code.

Architecture

Programming environment

  • The XCAP Server is developed in Java using jdk1.5 and jaxp interfaces.
  • Tomcat 5.5 has been used to provide the servlet interface for the xcap server.
  • Linux 2.6.9-22.0.1.EL Red Hat has been used for testing
  • SIPc XCAP client has been developed in Tcl/Tk
  • XCAP client has been developed in C++
  • For XPATH traversal Saxon 8-b has been used
  • For xml SAX parsing in TCL, tclXMl has been used
  • For xml DOM parsing in TCL, tDom has been used
  • Tk has been used for widgets and UI

Test Environment

  • Unix machines running Linux 2.6.9-22.0.1.EL Red Hat having public IPs
  • SIPc and C++ client used to send XCAP requests
  • From both inside and outside the Columbia network

Modules

AppUsage

 1. Object Model
2. It is a module that encapsulates the creation and references of different application usages.
3. Module follows classical factory patten, defining Singleton AppUsageFactory with which the AppUsages register.
4. Each new application usage need to implement the AppUsage class and provide the class name in a applocator.txt file for dynamic loading by the XCAP Server.
5. An AppUsage is identified by the following attributes: 
    

  • appName                  : specifies the application name
    • 

  • default Namespace prefix : specifies the application default namespace
name
    • 

  • default Namespace Value  : specifies the application default namespace
    • 

  • schema Locations         : specifies the application schema location
    • 

  • auid                     : specifies the application usage aiud
    • 

  • mimetype                 : specifies the application usage mime-type
    •
6. Currently presence-rules loader and resource-lists loader have been implemented. The applocator.txt file has the following entries
edu.columbia.xcap.appusage.ResourceListLoader
edu.columbia.xcap.appusage.PresenceRulesLoader

Parser

 1. Object Model
2. Module encapsulates the XPATH parser implementation.
3. The previous xcap server implemented its own XPATH parser. This was superceded with more conventional XPATH parsers like Xalan and Saxon, both of which implement JAXP standard, sometimes augmenting the JAXP feature.
4. The augmented feature has not been used and only JAXP specification implementation has been adhered to for inter-operability.
5. Saxon-8.5b XPATH specification 2 compliant parser has been used. This was chosen over Xerces, Xalan, Pathan, Crimson as
  • benchmarking results showed saxon to be faster in processing XPATH traversals.
  • benchmarking results showed saxon to be faster in validating xml against the given schema.
  • light weight, JAXP implementation parser
  • Very active online support. I got responses within 12 hours to all my queries
  • support for XPATH specification 2

6. All parsers implement Parser interface.
7. Each implemented parser promises to implement both XPATH traversal function and namespace retrieval function.
8. Additioanally JAXP serializer is also encapsulated as a static method here.
9. SchemaValidator validates the given XML against the specified application usage specific xsd. Warnings are treated as errors.

Store

 1. Object Model
2. Module encapsulates xml repository interface and is file system implementation.
3. Interface abstracting the details of the xml document handlers implemented.
4. DocumentHandler class within this module takes the responsiblity for parsing and validating XCAP URI. It also binds both default and specified prefixes to the XCAP URI. 5. Filesystem implentation of the document handler is acchieved through FileDocument Handler implementation of the DocumentHandler Class.

Error

 1. Object Model
2. Module providing support for detailed XCAPConflict xml items. This module has a base class ErrorCodes which the others inherit, thus making adding of error generalized. The errors include
  • CannotDelete
  • NoParent
  • NotXMLFrag
  • CannotInsert
  • NotUTF_8
  • NullError
  • ConstraintFailure
  • NotWellFormed
  • SchemaValidationError
  • ErrorCodes
  • NotXMLAttValue
  • UniquenessFailure

Servlets

 1. Object Model
2. The module abstract the incoming HTTP requests. It delegates the GET, PUT, DELETE calls to respective handlers. A more generalized method of callback through event types via service handlers has been implemented and tested. The former is kept in the final code.
3. The class XCAPServer implementes Java HttpServletInterface. A new instance of this is created and operated in the thread for each request. The server (tomcat) maintains a thread pool for the servlet instances.
4.The class dynamically loads the application usages specified in the applocator.txt file. Each of the application usage specified is instantiated using Java Reflection APIs and are registered with the AppUsageFactory

Test

 1. Module forms a place holder for unit and integration tests.
2. It also is a place-holder for obsolete files, which are not ready to be deleted.

Utils

 1. Object model
2. Modules responsible for maintaining utility classes. 3. The utility classes currently defined are
  • Base64Coder
    • Base-64 Encoder to encode values from md5 hash output to calculate E-Tag
  • DOMXMLParser
    • Wrapper over jaxp and saxon dom parsers
  • HttpSemantics
    • Wrapper over previous xcap server code to check for E-tag and other conditional HTTP headers.
  • MRUCache
  • MRUObject
    • Fully implemented, but not integrated Most Recently Used cache
  • ResultObject
    • Wrapper over the result returned by HTTP requests
  • SchemaConstants
    • Place holder for constants for maintainability
  • Service
  • XCAPException
    • Module Exception class, which uses detailed conflict reports to express errors.

Design Constraints and Considerations

  • Design needs to have sufficient modularity so that any major changes to the XCAP draft should not affect the existing code.
  • Design needs to be completely independent of any application usages.
  • Design should support restrictions defined by the application usages which are separate from XML Schema restrictions
  • Design should be pluggable, so that any module can be plugged into or plugged out
  • Since the files could be large, implementation of the store (as suggested during demo) should be benchmarked.
  • Time for development of test client, SIPc and a simple http client side library needed to be kept in mind

Program Documentation


Measurements

  • Lines of Java code : ~10000
  • Lines of tcl/tk code: ~2000
  • Line of C++ code : ~1500

References

1 XCAP draft : SIMPLE Internet-Draft Expires: April 27, 2006
2 HTTP 1.1 : Network Working Group Request for Comments: 2616 Obsoletes: 2068 Category: Standards Track
3 Presence Rules : SIMPLE Internet-Draft Expires: April 27, 2006
4 List usage : SIMPLE Internet-Draft Expires: April 8, 2005
5 SIPc : Columbia SIP User Agent (sipc)
6 Xiaotaow
7 Kodiak Networks
8 List of previous xcap drafts
Last updated: 1998-05-13 by Henning Schulzrinne