Design and Implementation of a Device Description Repository

1 Introduction

Web access from mobile devices suffers from problems that make the Web unattractive for most mobile users. W3C's Mobile Web Initiative (MWI) [MWI] proposes to address these issues through a concerted effort of key players in the mobile value chain, including authoring tool vendors, content providers, content adaptation software vendors, handset manufacturers, browser vendors and mobile operators. The objective of the W3C Mobile Web Initiative is to enable access to the Web from mobile devices. It is recognized that this will generally require adaptation of web content and therefore an understanding of the different characteristics, features, behaviours and limitations of mobile handsets.

There is a need to foster the provision of, and access to, these consistent and reliable, Device Descriptions that can be used to help develop and deliver high-quality mobile web applications to the world's mobile devices. Device Descriptions are pieces of information relating to devices that may be used to categorise or distinguish them. As an example, a description of a device may provide information about the type of markup supported by the browser, the size and resolution of the screen and the presence of various input features.

Furthermore, nowadays, it is a fact that there is a convergence between different services in the mobile world, where a mobile device has many user agents inside (browser, instant messaging, push to talk, broadcast channels, etc). In this way, a lot of services could make use of the device description, so we consider a key point to think in fully horizontal solutions, which include all the services and actors.

Within MWI [MWI], Device Description Working Group (DDWG) [DDWG] is chartered to produce a set of technologies that allow the universal access to device descriptions, which leverage the existing approaches. One of the main deliverables of DDWG first charter has been the requirements of a Device Description Repository (DDR) [DDWG-Repository-Requirements]. Next charter will have to do with the implementation of such device repository. The current paper states Telefónica's position with respect to the development of Device Description Technology and Repository.

In the first section we will briefly describe the current state of the art on device description and in the following we will outline our position regarding all the important questions that should be addressed during the workshop.

2 State of the art

At the moment the most popular technologies for device description are WURFL (open source initiative) [WURFL] and UAPROF [UAProf], OMA [OMA] standard based on CC/PP [CCPP].

UAProf is normally published by device vendors and its vocabulary includes hardware and software characteristics as well as WAP specific features of the mobile terminal and associated transport network. Subsequent updating, to UAProf V2.0, by OMA has based the definition on the latest version of RDF [RDF] and RDF Schema [RDF-Schema]. Current lacks of UAProf are:

• There is not a set of mandatory properties that each device vendor must provide.
• There is no advanced data model for simplifying device description provisioning.
• There is a limited vocabulary set that is not oriented towards the development of mobile web applications.
• There is no standard repository of UAProf documents. There has been approaches such as the UVMT Tool [UVMT-Tool] hosted the OMA portal, which have not had a good acceptance from the market.

WURFL is a free, open source project that provides an alternative source of information to UAProf. It tries to provide a comprehensive resource of device information, and contains device information for 6000 variants of devices. Because WURFL is open source, anyone can correct device information, not just device manufacturers. WURFL provides its own XML [XML] format for device characteristics description which is based on an inheritance fallback model. Current limitations of WURFL are:

• There is not a distributed model or central/public repository. Instead of that there is an ever-growing unique XML file.
• There is not a validation and trust model for device description. Anyone can collaborate and may provide an inaccurate device description.
• There are neither versioning nor updates publication mechanisms.
• There is no guarantee about how long will be supported this repository.

In the mobile space also exist other actors and stakeholders that manage a big amount of device information (incompatible) which initial importing source are both WURFL and UAProf. We know that content adaptors such as MobileAware or Volantis have this kind of stuff, and furthermore, mobile operators maintain its own device description databases that provide information for the mobile portals or internal content adaptation processes performed at the network level.

It is important to remark that today none of the existing technologies is based on the concept of a global public or federated repository of information. Also there are not mechanisms to allow the definition of trust mechanisms for the information contained by these sources of information. Furthermore, there are no standard and universal APIs to access device descriptions.

3 Device Description Repository Architecture

Repository architecture should be open and extensible and should cover different models:

• The repository is deployed locally under application working environment.
• The repository is maintained privately by an organization. It is used by different mobile applications within that organization.
• There is a fully distributed and federated model where different device descriptions are maintained by different organizations. This model might lead to the definition of a worldwide public repository.

In all cases repository APIs will hide the underlying architecture to the user.

In all the above scenarios, it should be provided mechanisms that allow an application to override locally a device property. We are thinking in something similar to the successful WURFL patch file.

The actual protocols used for repository access will be left to each implementation, as they will be transparent to repository clients by means of the APIs. Nevertheless, we foresee that SOAP [SOAP] over HTTP will be the most common protocol for repositories published on Internet.

The fully distributed model will be the more challenging, and we envision that technologies related to content syndication and aggregation, such as RSS [RSS], are going to play an important role in this fully distributed model. We foresee that different actors of the ecosystem could provide new device descriptions or updates using universal RSS feeds.

4 Device Description Vocabulary and strong data typing

In our opinion, till the moment, DDWG has not paid enough attention to the definition of a standardized device description vocabulary and framework that specify what are the device properties to be managed, at least, by mobile web content adaptation processes. The properties to be standardized must be aligned with those used by other technologies such as CSS Media Queries [Media-Queries] or by other working groups such as Device Independence Working Group [DIWG]. We envision that this standardization effort could affect the work performed under the mentioned working groups and we think that early liaisons must be established with them.

We think that there is an opportunity to define a framework for defining vocabularies associated to device descriptions. That framework could be structured around modules and profiles that define groups of capabilities related to different device features (browsing, MMS, SMS, WAP Push, J2ME, ...) and that could be of interest to different members of the mobile development community.

We think that W3C-DDWG vocabulary standardization effort should focus on mobile browsing capabilities of user device, recognizing the fact that other organizations, such as OMA, will define and standardize other vocabularies describing properties different than those related to browsing. In order to avoid further integration problems in the developed framework, and leverage all the previous works made in this group, we think it should be established liaisons with OMA.

Nevertheless our Device Description technology, repository will be prepared for the integration of different vocabularies thanks to the framework developed. We also envision the existence of highly-specialized Device Description Repositories provided by different companies. For example, at the moment there is an specialized J2ME device description database provided by the open source product J2ME-Polish [J2ME-Polish]. In a future this database could become a DDR specialized in the J2ME module.

Strong data typing should be achieved by means of using existing W3C technologies, mainly XML-Schema [XMLSchema]. Each device property must have a type and if necessary measuring units, specially in those properties related to sizes.

5 Device Description Data Model

The existence of an advanced data model is fundamental for the definition of a successful device description technology and its repository. In the case of WURFL inheritance has demonstrated to be a simple but powerful method to support device description and provisioning, following a fallback principle that minimizes the cost of introducing new devices.

We expect that W3C repository implementation maintains inheritance as a feature or even leverage it by defining complementary mechanisms, such as those that allow a device to belong to one or more categories, enabling the definition of clusters of devices.

The data model also should be prepared for supporting device description versioning issues, including the deprecation of devices.

6 Device Description Repository Persistence

It should be left to the implementation the actual technology that will provide persistence to the Device Description Repository. There will be implementations based on XML, databases, indexed files, text files, or even based on emerging content repository standards such as JSR-170 [JSR-170].

Interoperability at data level will be achieved by means of a common exporting format that will be based on existing W3C technologies, preferably XML. This exporting format will allow to perform initial loads or backups of device descriptions.

7 Device Description Provisioning

The provisioning of new devices should be done in a very straightforward manner. The provisioning mechanisms should be prepared for supporting the following scenarios:

• It is available a Device Profile, for example, an UAProf, and someone wants to add it to the repository.
• A user knows the properties (by means of testing) of his brand new device, which is similar to an existing one in the repository, and wants to add it.
• There is a collection of device descriptions, specified in the device description repository exporting format, and someone wants to add it to the repository.
• Someone has detected that the value of an specific property of a device is not accurate and wants to correct it, so generating a new device description version.

There should be workflow mechanisms that govern the process of device description provisioning. Updates to device descriptions will have to be finally approved by the repository data manager.

There should be mechanisms that allow to mark as private different device descriptions, for example, to allow access to them only to pay-per-use users. This could be useful in a scenario, where an organization publishes a repository on the Internet and gives free public access, but wants that the newest device descriptions are only available to users that have a payment account.

Device descriptions will be always under versioning control.

Device description updates will be available as RSS feeds in order that existing tools can automate the process of receiving notifications of new device descriptions when they are available.

8 Device Description Repository Security Model

Device description repositories will have to implement a security model which should include the following user profiles:

• Anonymous User. An anonymous user who connects to the DDR to retrieve device descriptions. This user will have read permission to all the device descriptions made public by the repository.
• Premium User. A user who pays for using the DDR and connects to it to retrieve device descriptions. This kind of access allows a user to read all the device descriptions of the repository (public and private).
• Provisioning User: A user who has write permission to provision new devices or to update existing ones. The additions or updates will not be available to other users until the repository data manager approves them.
• Validation User. A user who is in charge of validating (and correcting if necessary) device descriptions by means of testing them on each real device. For example, operator people working in the device certification department could achieve this role.
• Repository Data Manager. This user will be in charge of approving new device descriptions or updates to existing ones. The user in this role has the last word in accepting and making available new device descriptions.

9 Device Description Validation and Trusting Model

Device Descriptions could come from different sources (open source, device vendors, mobile operators, content adaptors) and its information could affect the final quality that users perceived. Incorrect or malicious information resulting in a buggy application or service making its owner lost money or clients, which could have an important impact on business. This problem could even be worse in a fully distributed model there will be different sources for device descriptions. This is the rationale to have technologies that allow the validation and trusting of device descriptions.

We understand validation as the process of verifying that a device description is correct by means of actually testing the property values in the physical device. The workflow process that models the device description feeding should be aware of validation and users should be able to know if a device description is validated or not. There will be critical environments where a device description will not be made available until the validation team has validated it against each device.

Trusting implies that device description information is digitally signed by an organization which guarantees that the data made public cannot be repudiated and that really comes from that organization. The consumer of the device description could claim on that organization if there are errors on that. In a device description repository there will be both signed device descriptions and not signed. Furthermore, in open source repositories there will be no signed device descriptions. As in the validation case, repository users should know in every moment if they are using a signed device (and who signs it) description or not. In open source repositories there will be device descriptions that are neither validated nor signed.

The technology supporting trusting should be based on existing standards. We foresee that current W3C standards and technologies such as XML Encryption and Key Management [XML-DSIG] could be used for this purpose.

10 Device Description Repository Interfaces and APIs

DDR APIs will be defined using OMG-IDL [OMG-IDL] (Interface Definition Language). This will provide universal access to the Device Description Repository from any programming language, network or hardware architecture. Nevertheless, taking into account the fact that DDRs will also be published on the Internet, DDR interfaces should also be described using WSDL [WSDL] in order to implement an adaptation layer between DDR and Web Services. The WSDL definition of the APIs will be automatically generated by means of the automatic translation between IDL and WSDL. To perform this automatic generation the only restriction will be to avoid advanced IDL features, such as the any type.

Device Independent Working Group has been working in the definition of APIs to retrieve static and dynamic properties that comprise the delivery context (DCI interface) [DCI]. As device properties are part of the delivery context, actually an static one, we think that the design of the DDR APIs should be aligned with the existing work performed under DIWG.

11 Device Description Repository Tools

In order to provide a friendly human interface to the device description repository, implementations will have to develop different graphic tools. We envision at least the following:

• Web Admin tool. It will provide to repository managers a user-friendly interface for feeding and managing the repository.
• Web Query Tool. It will allow final users or developers to query, search and browse device descriptions.

12 Relationship with OMA-UAPROF and OMA-DPE

Currently at OMA there are different activities regarding device description. These activities are related to the extension of the UAProf and the definition of a Device Profile Evolution (DPE) [OMA-DPE] technology, that has to do with obtaining device capabilities that may change during the course of a service. DPE tries to cover all the aspects related to dynamic properties of the devices (battery and memory remaining, CPU load, etc), and the ability of the devices to convey these dynamics properties in real time to an application service provider..

Device Description Technology developed under W3C should be fully compatible with OMA technologies allowing a seamless integration between them. We must ensure that integration at least in the following points:

• Compatibility at least at the provisioning level of UAProf descriptions and W3C DDR
• Compatibility between W3C vocabulary framework and OMA existing and future vocabularies.

To achieve so ambitious objectives it should be established liaisons between the two organisations. Internally, we are coordinating efforts between our OMA and W3C representatives but we expect a more formal liaison between OMA and W3C.

Regarding dynamic capabilities we foresee complementary objectives between OMA-DPE and the work performed under DIWG about retrieving static and dynamic properties that conform the delivery context (DCI) [DCI]. A correct alignment between DDR APIs, OMA-DPE and DCI APIs, avoiding duplicated efforts, will be fundamental to obtain good results under our standardization task.

13 Reference Implementation of a Device Description Repository

The reference implementation of the DDR should be developed under an open source schema. The development effort should be coordinated by W3C and sponsored by different members of the W3C-MWI. Telefónica is very committed to be involved with these implementation activities, and offers its open source development infrastructure (based on G-Forge [G-FORGE]), MORFEO, [Morfeo], [Morfeo-Forge] to host the implementation project.

14 Conclusions

There is a need for new device description technology that overcomes current issues present in today available technologies. This new development effort should be based, if possible, on existing technologies. The main features of this new generation technology will be:

• A flexible data model for device description which simplifies provision and facilitates device clustering.
• An standardized and well-defined vocabulary capable of integrating vocabularies defined by other standard bodies such as OMA. In this way, proliferation of proprietary solutions will be avoided.
• A simple provisioning model based on standardized XML formats for interchanging device descriptions.
• A validation and trusting model for device descriptions.
• A repository for accessing device description with an open and flexible architecture, which could be distributed and federated.
• A security model that defines the different user roles and access permissions to the repository.
• An universal API for accessing the repository, which will be independent of the programming language.
• Graphical tools that provide an user-friendly view of the repository.

This technology will be fully integrated with existing and future initiatives such as OMA-UAPROF and OMA-DPE.

Our vision also encompasses the development of a reference implementation of the device description repository under an open source schema. We believe that providing public repositories of device descriptions in an standard and global manner will improve the development of the mobile web, and Telefónica as an integrated telecommunications operator, will benefit from that situation.