The overall application architecture for an internet and a mobile internet application does not differ fundamentally - indeed both using the same lower layer transport protocols and similar mark-up languages - the presentation to the end-user will have to differ because mobile end-user devices will remain smaller and thus limited in terms of input-output capabilities compared with traditional personal computers. Hence, applications will benefit from the ability to adapt the generated content to optimally to the capabilities of the end-user device and the preferences of the end-user himself.
The content generation process is driven by parameters associated with the request for information. Hence, if we augment such requests with additional information to describe the capabilities of the device and the end-user's preferences, we enable the application to exploit these and generate better suited mark-up output to be rendered on the end-user device. We refer to this additional information as composite profile information (CPI).
This position paper lists the CPI requirements we have identified, reviews and criticizes the current standardization efforts, and briefly describes an implementation of a standardized profile environment.
The requirements for handling of such capability and preference profile information can be summarized as follows:
Current internet technology does not use preference information on a wide-spread scale. In part, this is due to the limited possibilities of forwarding preference profile information with an HTTP request. The HTTP/1.1 standard [1] supports a limited set of header fields of which only the header-field User-Agent allows to identify the end-user's browsing environment. Additional preference information can be conveyed via the various Accept header fields, but the range of capabilities which can be described through these means remains limited.
Common practice thus is to statically associate a device profile with the device's User-Agent information. This profile is then accessed by the origin-server based on the HTTP request's header value.
A more dynamic approach is advocated in the model of the client capabilities and preference profile (CC/PP) [3]. It proposes composite preference information grouping device capabilities and user preferences into a set of components. For each component, a possible set of default property values is indicated through the inclusion of a URL reference. Each component may also contain one or more properties which override the default values. Every property defines its name, its type, and possibly a set of values (for enumerations, for example).
A profile's components and their properties are specified in the profile schema or vocabulary. Thus, for different applications distinct CC/PP vocabularies can be defined. An XML based syntax, the resource description framework (RDF) [4] is used to externalize a CC/PP compliant profile and associated default profiles.
From an implementation point of view, the CC/PP proposal suffers from various shortcomings:
The WAP Forum has based its User Agent profile(UAProf) [8] work on the CC/PP and RDF framework. These have been extended with a specific transfer syntax for profile and profile differences, as well as resolution rules for property default and difference values. In addition to the Wireless Application Protocol itself, the proposed m-services initiative also requires adoption of the UAProf standard [2].
To describe the capabilities and preferences of a mobile end-user device, the UAProf vocabulary defines six components hardware, software, user agent, network, WAP characteristics, and push environment. The set of available scalar property types is fixed and comprises numerics (integer), booleans, dimensions (a two-dimensional metric), and (string) literals which are also used for enumerated values. In addition to these base types, multi-valued types are also supported using the RDF collection mechanism. Bags indicate an unordered, multi-valued set, alternatives describe a choice from multiple values, and sequences provide an ordered set of values. The application of profile differences to base profiles is driven by resolution policies that are associated with each property. Possible resolution policies are locked (value can be set once), override (value can be modified), or append (for multi-value sets only).
The UAProf standard includes a transport syntax for transporting profiles and profile differences. profiles references, i.e. their URLs, are contained in an x-wap-profile HTTP header and profile differences as RDF/XML data in x-wap-profile-diff headers. The x-wap-profile header refers to the profile differences through an index and includes a checksum (MD5) of the difference value for validation of its integrity.
Other transfer syntaxes are based on RDF/XML documents embedded in MIME multi-part messages [6] or on a distinct set of HTTP extension headers [7]. The UAProf schema makes incomplete use of the already incomplete CC/PP schema formalism, and embeds property types and resolution policies in XML comments. Further shortcomings of the CC/PP framework and the UAProf schema in particular are:
At the IBM Zurich Research Laboratory we have implemented middleware software which performs default resolution and profile difference evaluation for UAProf compliant profiles. An API implemented in C and in Java exposes operations such as:
The implementation has been done in the C language for performance reasons. On top of our base CPI library, we have implemented a Java wrapper using Java Native Interface (JNI). Additional software was written to use the CPI library in an Apache module or a Java Servlet context.
Several functional units can be distinguished in our UAProf/CPI implementation. An XML parser produces a DOM-like [5] representation of RDF/XML data on which RDF syntax rules are verified. The UAProf schema information drives the parsing of the RDF/XML document representing the profile.
Since no fully machine readable formalism has been defined for the UAProf schema, we have hand-crafted an extended database model to capture CC/PP compatible schemata and applied it to the UAProf schema. Thus, our CPI library can draw on machine accessible UAProf schema information. It is used in processing profile and profile difference data. Our database model for schemata captures a schema's components, their types, and the property types. For property types, we store its name, its type, and its resolution policy.
After verification of the profile's compliance with the schema and the RDF/XML syntax, default resolution is performed. For performance reasons, we have implemented a two level cache to hold default component values. The first level is an in-core cache; the secondary level uses a relational database. Hence, our CPI library retrieves default components - referenced via their URLs - only once across the internet to load the default component caches. Depending on the lifetime of the CPI library instantiation (e.g. per HTTP request or across multiple HTTP requests), access to a default component is serviced via the database cache or the in-core cache and becomes independent of network latency and throughput.
The default component cache can also be pre-loaded during initialization of the CPI library to avoid penalizing the very first profile resolution with retrieval of default component values.
A similar two-level cache approach is used for resolved profiles. Indeed, there is a high likelihood that clients present identical profiles with a series of subsequent HTTP requests since the device's capabilities and the user's preferences are unlikely to change between subsequent HTTP requests. We detect this by checksumming the HTTP headers related to the profile information and using the checksum value as a look-up key into a profile cache. Thus, if subsequent requests carry identical profile information, profile resolution is only performed once; profiles for ulterior requests are serviced out of the profile cache.
Another implementation issue has been the handling of profile matching which requires an ordering function on profile property values. For simple scalar types, such as integers or even dimensions, the ordering function is simple. However, for literal enumeration values no simple relationship can be defined: lexicographical ordering, for example, is not meaningful.
Our implementation therefore associates an explicit enumeration of the relations between literal enumeration values. Evidently this externalized encoding of the order relationship requires O(n2) space in the schema database, but supports convenient extensibility of the order relationship for a given enumeration type without rebuilding the CPI library when new property values are introduced.
[1] R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1. IETF, June 1999. RFC 2616.
[2] GSM Association. M-Services Guideline, May 2001. PRD AA.35.
[3] G. Klyne, F. Reynolds, C. Woodrow, and H. Ohto. Composite Capability/Preference profiles (CC/PP): Structure and Vocabularies. W3C, June 1999. http://www.w3c.org/TR/NOTE-CCPPexchange.
[4] Ora Lassila and Ralph R. Swick. Resource Description Framework (RDF): Model and Syntax Specification. W3C, 1999. http://www.w3c.org/TR/REC-rdf-syntax.
[5] W3C. Document Object Model (DOM) Level 1 Specification, October 1998. http://www.w3.org/TR/REC-DOM-Level-1.
[6] WAP Forum. Wireless Application Protocol: Push Access Protocol (PAP), April 2001. WAP-247-PAP.
[7] WAP Forum. Wireless Application Protocol: Push OTA Protocol, April 2001. WAP-235-PushOTA.
[8] WAP Forum. Wireless Application Protocol: User Agent profile Specification, October 2001. WAP-248-UAPROF.