Context Key Task Force

Members

• Anders (DRUTT)
• Jose Cantera (TI+D)
• Jo Rabin (dotMobi)
• Matt Womer (W3C)

Problem Statement

A “context key” is something that represents the hardware and/or software of the delivery context so that the right description data can be retrieved from the DDR.

What is the best mechanism for representing the context key in terms of:

Design Goals

• Low maintenaince costs of the solution (Suggested by Rotan)
• Simplicity
• Interoperability
• Compatibility with existing solutions

Solution Brainstorming

Provide a normative algorithm for generating the key (Rhys Lewis)

This solution was suggested by Rhys Lewis during the Darmstadt F2F meeting. Rhys could you provide further info on this proposal?

Pros

Cons

A key based on URIs (JMCF)

URIs are well-known mechanisms for identitying resources in the WWW. Why not using them?

We could set up a base URI for identifying the whole space of devices (software and hardware) and the concatenation of a string to that base URI could be the identification of a device or a browser. For example

Base URI: http://www.w3.org/2007/DDWG

http://www.w3.org/2007/DDWG/Nokia/6670 would identify the Nokia 6670.

http://www.w3.org/2007/DDWG/Opera/Mini/3/4 would identify Opera Mini 3.4

How the rest of the URI could be generated?

<Device_Manufacturer>/<Device_Model>/Version/Subversion/....

So if we create a key based on a pair of URIs, for example

(http://www.w3.org/2007/DDWG/Nokia/6670,http://www.w3.org/2007/DDWG/Opera/Mini/3/4)

In the previous example we are referring to Opera Mini Executing on Nokia 6670.

Issues

How to normalize manufacturer's names, device model's, etc. For example, if in a country a manufacturer changes its name??? How to deal with upper-case, lower-case issues ....

(From Jo) I don't know that the key needs to be known outside the system in which it is being used. In which case specifying its exact properties in not necessary. For example, if the key is found by querying the DDR Give me the device that has the folowing UA string and the key is then used in the query get me the device characteristics that match the following key then the format of the key can be opaque.

... I'd argue that there are benefits to knowing that the key is actually a list of values and that one can anticipate that the response to the device characteristics query is in fact a set of device chracteristic structures, but since we haven't specified that yet, it's not clear that would be the case (it might return a single, merged, characteristic structure, for example).

From Jose: In Darmstad we discussed the same issue. The key can be opaque but then interoperability problems are going to appear.

(From mdw) I think using URIs for this won't receive any objections. CC/PP does this currently. A place where CC/PP falls down that I think is going to be hard to overcome is how to merge two profiles. While CC/PP does allow multiple URIs and diffs, it is hard to manage.

How can the user agent generate a diff? If the device and the browser represent one unit that is one profile that is burned into the device, having the UA generate the diff is easy as it already knows everything there is to know about the device. This seems like the case that CC/PP is suited well to handle.

Once additional UAs that aren't paired to the device are considered this becomes more difficult. Adding a third party browser to the device requires that the UA know what device it is running on, know how to find the profile URI (or generate this profile programatically via system calls to the OS), fetch it's content, parse it, merge it with the software characteristics of the UA and then generate the diff that it will send on to the content server. If you're a UA developer, this becomes a shot in the dark. With the number of devices out there you won't be able to test on all of them, and you probably don't want to keep non-tested devices from working. Perhaps this is where the Default Delivery Context comes in handy, and if a UA isn't capable of querying a device for it's characteristics, it can merge itself with a profile for the DDC?

Anyway, my point was that I think this same problem will rear it's head here as well.

Pros

Cons

A key based on ... (Proponent)

Pros

Cons