Computer Science Dept.
New York, NY 10027
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.
XCAP stands for XML Configuration Access Protocol. It defines the term XCAP URI
which, leverages HTTP  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
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.
For example SIP presence framework requires
- XCAP root
- Document selector
- AUID (Application Usage Identifier)
- XUI (XCAP User Identifier)
- Path selector
- Node selector
This can be conveniently achieved through the XML Configuration Access
- 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
Previously developed XCAP Server based on the earlier
specification . However
- The scope of the project defines implementation of XCAP Server as per the
specification given by IETF draft
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 
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 
Support for integrating this with Columbia's Presence Agent has been
- 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
- SIPc , 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 
- 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 , 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
- Any changes made in the SIP client (SIPc) while it is offline can be
cached and applied once the SIP client comes online
The server hence developed, has been re-designed but reuses pieces of the
- 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
- 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
- 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
- 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
1. Object Model
2. It is a module that encapsulates the creation and references of different
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
5. An AppUsage is identified by the following attributes:
6. Currently presence-rules loader and resource-lists loader have been
implemented. The applocator.txt file has the following
- appName : specifies the application name
- default Namespace prefix : specifies the application default namespace
- 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
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
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
9. SchemaValidator validates the given XML against the specified application
usage specific xsd. Warnings are treated as errors.
- benchmarking results showed saxon to be faster in processing XPATH
- 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
- support for XPATH specification 2
1. Object Model
2. Module encapsulates xml repository interface and is file system
3. Interface abstracting the details of the xml document handlers
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.
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
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
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
1. Object model
2. Modules responsible for maintaining utility classes.
3. The utility classes currently defined are
Base-64 Encoder to encode values from md5 hash output to calculate E-Tag
Wrapper over jaxp and saxon dom parsers
Wrapper over previous xcap server code to check for E-tag and other
conditional HTTP headers.
Fully implemented, but not integrated Most Recently Used cache
Wrapper over the result returned by HTTP requests
Place holder for constants for maintainability
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
- 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
- Lines of Java code : ~10000
- Lines of tcl/tk code: ~2000
- Line of C++ code : ~1500
draft : SIMPLE Internet-Draft Expires: April 27, 2006
HTTP 1.1 :
Network Working Group Request for Comments: 2616 Obsoletes: 2068 Category:
Rules : SIMPLE Internet-Draft Expires: April 27, 2006
usage : SIMPLE Internet-Draft Expires: April 8, 2005
SIPc : Columbia
SIP User Agent (sipc)
List of previous xcap
Last updated: 1998-05-13 by Henning Schulzrinne