Device Description Repository Requirements 1.0

1.1 General

This document describes the use cases for a Device Description Repository (DDR). Each use case is analyzed in order to determine the behavior expected of a DDR in order to realize it. These expected behaviors are captured as high-level requirements, which when normalized across all use cases, lead to a discrete set of DDR requirements.

A DDR forms part of the Scope and Deliverables of the MWI Device Descriptions Working Group (DDWG) Charter, based on the motivations described in the Device Description Landscape document.

1.2 Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

1.3 Scope of Requirements

The requirements in this document cover the behaviors expected of a Device Descriptions Repository. The requirements are at a high-level and, with the exception of [DDR-TECHNOLOGY], do not prescribe or recommend a particular technology solution. For the same reason the implementation, data provisioning, security and operation of a DDR are not in scope of this document.

The Scope of the requirements is bound by the scope of the DDWG Charter, specifically Identification of device characteristics ... that enhance the user experience of Web browsing, while mobile.

1.4 Conformance

A Device Description Repository will be DDWG DDR conformant if it meets all the mandatory requirements stated in the High level requirements section of this document. Any other optional DDWG DDR requirements, and non-DDWG functions, may also be implemented.

2.1 Fundamentals

The DDR must, at a minimum, support:

1. identification of components of the delivery context

2. the retrieval of device descriptions

2.2 Requirements

The following are motivated by the use cases:

[DDR API]

The DDR MUST expose an API through which device descriptions can be retrieved.

[DDR-MEASUREMENT]

If a value returned by the DDR is an indication of measurement (such as width or resolution) then the units of measurement are expected to be unambiguous to the requesting party: i.e. either the vlaue returned explicitly declares the measurement unit, or the requesting party specifically asked for the value in a particular unit ('screen width in cm').

[DDR-CONTEXT-KEY]

The DDR is expected to attempt to return a device description (or element thereof) based on identification of the hardware and/or software that the description relates to (the 'context key').

[DDR-INSUFFICIENT-CONTEXT-EXCEPTION]

The DDR is expected to follow exception handling requirements as detailed in the DDRAPI document.

[DDR-VALUE-RANGE]

The DDR is expected to return a range of all known values of a particular device capability for a given context key if requested to do so.

[DDR-CONTEXT-AMBIGUITY]

Should the DDR not receive enough information to accurately determine the context key, then it is expected to either (a) make a 'best effort' guess based on the evidence available, (b) return all possible values for the aspects of the description queried, or (c) return an exception as detailed in the DDR API document.

The following requirement is a goal of the DDWG:

[DDR-TECHNOLOGY]

It MUST be possible to realize the DDR and its exposed interfaces through different technologies including but not limited to Web services.

3.1 Use Case 1: Optimized Web content for mobile devices

Bruce is a Web content author who wishes to provide an optimized user experience for those users accessing his site via a mobile device. Using standard HTTP request headers, he is able to recognise the mobile handset and browser software making the request. He queries a DDR using the handset and browser as query criteria, and asks for the width of the handset screen in pixels. The DDR uses the query criteria to identify the device used, and returns the screen width in pixels, accordingly.

Motivates: [DDR-API], [DDR-CONTEXT-KEY], [DDR-MEASUREMENT]

3.2 Use Case 2: Querying a Value range

Hal is also a Web content author who queries a DDR for information that will improve mobile users' browsing experience. He wishes to know all the image formats supported by a particular device/browser combination. As such he queries the DDR, passing in a device/browser identifier. The DDR uses this information to return all the image formats supported in this case.

Motivates: [DDR API], [DDR-CONTEXT-KEY], [DDR-VALUE-RANGE]

3.3 Use Case 3: Context ambiguity

Carter wishes to determine the markup formats supported by a mobile device that has requested his Web page. He queries a DDR for this information, but only passes in a device hardware identifier, without an indication of the browser used. As such the DDR makes a 'best effort' guess that the browser is the one that comes pre-installed on that device, and returns a range of supported markups for that browser accordingly. Note: where context is ambiguous, the DDR may instead choose to throw an exception, or return all possible values based on the available evidence: it is likely that different aspects will determine different behaviour.

Motivates: [DDR-CONTEXT-AMBIGUITY]

3.4 Use Case 4: Insufficient context available

Diana wishes to determine the screen resolution in pixels of the device querying her Web page. However she is only able to determine the browser, but not the device hardware, making the request. When queried, the DDR is unble to resolve the context key of the request and throws an exception.

Motivates: [DDR-INSUFFICIENT-CONTEXT-EXCEPTION]