Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document provides an overview of the role of delivery context in achieving a device independent Web. It describes the kind of information that may be included in the delivery context, and how it may be used. It surveys current techniques for conveying delivery context information, and identifies further developments that would enhance the ability to adapt content for different access mechanisms.
This document is one of a series produced by the W3C Device Independence Working Group. Other documents in the series address the implementation of solutions to the requirements raised here. For example, there are documents in the series reviewing current techniques that can be used to address these requirements and exploring how future versions of existing W3C specifications can provide solutions.
Details of the entire series of documents can be found on the W3C Device Independence Activity home page.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a W3C Working Group Note. It represents the views of the W3C Device Independence Working Group at the time of publication. The document may be updated as new technologies related to the delivery maxf context emerge or mature. Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document is one of a series produced by the Device Independence Working Group(Member Only Link), part of the W3C Device Independence Activity. The DIWG activity statement can be seen at http://www.w3.org/2001/di/Activity.
Comments on this document can be sent to www-di@w3.org, the public forum for discussion of the W3C's work on Device Independence. To subscribe, send an email to www-di-request@w3.org with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The archive for the list is accessible online.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The earlier Device Independence Principles document [DIP] set out a number of principles that can lead to greater device independence in delivering Web content and applications. Terms from this document, and others related to device independence, are collected in the Glossary of Terms for Device Independence [GLOSS]. A link is provided to the Glossary definition when a term is first used in the following text.
The term delivery context, as used when discussing web delivery (first introduced in [DIP]), refers to:
A set of attributes that characterizes the capabilities of the access mechanism, the preferences of the user and other aspects of the context into which a web page is to be delivered.
In this document, the kind of information that may relate to the delivery context is described. The role of delivery context and adaptation in Web architecture is illustrated. Techniques for representing, conveying and processing delivery context are considered. Existing technologies that address these needs are reviewed. Areas that are under development by the W3C Device Independence Working Group to address remaining needs are outlined.
Delivery context includes many factors that could have some effect on the resultant experience of the delivered content by the user. Section 1.1 gives some illustrations of possible characteristics of the delivery context. Section 1.2 focuses on those characteristics that are particularly relevant to device independence.
There are many aspects of the delivery context that may influence which representation of some Web content is best delivered in response to a request. In this section, we hint at the range of potential characteristics that might be expressed in the delivery context. However, the set of potential characteristics is open-ended, so this list is only illustrative.
It is worth noting here that some of these characteristics could be considered as conveying sensitive information. Issues associated with privacy and trust are considered outside the scope of this particular note. Some of the challenges are discussed in 6.3 Trust and Privacy.
Some of the above characteristics may be intrinsic to, or can be evaluated by, the delivery device; others may be set, or overridden, by the user. Some characteristics may stay fixed for long periods (such as the communications protocols supported by the device); others may vary from one moment to the next (such as geographic coordinates, or temperature). Any particular device will only support a subset of all possible characteristics, though that subset may change over time.
Because of such variability, it is unlikely that any complete definition of a well-defined set of delivery context characteristics can exist. However, to allow for the evolution of a set of characteristics that can be of practical use in delivering appropriate content across a wide range of contexts, it is important that definitions of well-defined characteristics for subsets of the context can be re-used.
Diagram 1.1: Scope of delivery context characteristics
In some situations, there may be delivery context characteristics that are specific to a particular application. However, many characteristics may be useful to many applications. If each application were to define a different representation for its delivery context characteristics, it would require each delivery device to maintain delivery context information on a per-application level. Applications would need to know about devices, and devices would need to know about applications. This goes against the 'network effect' that the Web encourages, whereby Web content and applications, and the delivery devices use to access them, can be developed independently but in a mutually reinforcing manner.
For the remainder of this Note, we will focus on the issues that must be addressed when defining and sharing delivery context information in an application-independent way. This is particularly the case when trying to provide general solutions to achieve device independence.
Within the set of well-defined, application-independent delivery context characteristics, an important subset are those that may help deliver web content more effectively across a wide range of delivery devices.
Diagram 1.2: Scope of delivery context characteristics relevant to device
independence
The characteristics that are most relevant for achieving device independence are those that characterize the capabilities of the access mechanism, the capabilities of the network and some of the preferences of the user. In particular, a user may specify adaptation preferences and rendering preferences that affect the user experience they have of the delivered content (see [DIP] for further details).
For device independence, delivery context information is typically used to provide an appropriate format, styling or other aspect of some web content that will make it suitable for the capabilities of a delivery device. The adaptation required to achieve this may be performed by an origin server, by an intermediary in the delivery path, or by a user agent.
From the point of view of device independence, the main concern is accurately reflecting the capabilities of the access mechanism and the preferences of the user. Given appropriate information about the delivery context, the delivered content can be adapted to provide a functional user experience on that device, or may be further adapted to provide a harmonized user experience (as defined in [DIP]). The possible adaptations that could be performed on the available content can only be determined once the delivery context information is known.
The W3C Device Independence Group is defining a set of specifications related to the use of delivery context for delivering and running adapted content accross a wide range of devices. One activity is the Delivery Context Interfaces work that aims to provide a platform independent API for accessing delivery context information that can be used during both server-side and client-side content adaptation. This goal is described in more details in section 5.5.
In this section, motivation for more effective use of delivery context information is provided from the perspectives of users, authors and implementers.
From the perspective of the user, the technology for conveying delivery context information is largely invisible. For example, a user is not usually aware of the values inserted into an HTTP request header. But the user may need a mechanism to set preferred delivery context characteristics when necessary.
Some aspects of the delivery context, such as the underlying capabilities of the access mechanism, can be set automatically by software through internal configuration parameters. An example of such a characteristic might be the screen size of a visual rendering device.
Other aspects of the delivery context, such as user preferences, will normally require user configuration. User preferences related to user experience choices, may be managed by the user agent responsible for rendering some Web content. User preferences related to application personalization could also be transmitted as part of the delivery context, but are outside the scope of this document since they are inherently application-dependent.
Because the kind of content that is delivered may depend on the characteristics that are conveyed in the delivery context, it is important that the user is provided, through appropriate software and interaction, with sufficient flexibility to control those characteristics. This is particularly important where the needs of the user may differ from those provided in standard configurations.
Currently it is not clear how privacy of delivery context information is best addressed. The user may not wish certain pieces of information contained in the delivery context to be made available to untrusted components along the delivery path. For example, the user may wish information about their location to be made available to a trusted application, but not to any intermediate node through which the delivery context information may pass. This and other characteristics in the delivery context, individually or collectively, may indirectly constitute personally identifiable information, and so are subject to the security and privacy concerns considered in more detail in Section 6.3.
From the perspective of the application developer or content author, it is important to be able to access delivery context information in order to deliver the most appropriate kind of content.
In some situations, the application developer may rely on some underlying adaptation process to select and format the appropriate content version. For example, commercial image servers are available that can scale and convert the format of images to suit the rendering capabilities of different devices.
In other situations, the content author may indicate within their content that different selections should be made according to the client capabilities. For example, markup to express context-dependent styling has been included in CSS Media Queries [MQ]. Proposals to allow context-dependent content selection are under development [DI-sel].
In yet other situations, the application developer may explicitly create transformations which can adapt their content for different devices. For example, stylesheets written in XSLT may be applied to content expressed in XML to produce different deliverable presentation markup.
In order to make effective use of the delivery context information, the application developer needs the characteristics to be both well-defined and common across as many devices as possible. This raises issues of the definition and re-use of vocabulary elements, as discussed in Section 5.4.
Delivery context support may need to be implemented in system components such as user agents, web servers and proxy servers. From the point of view of a delivery context system implementer, several components need to be defined to ensure interoperable implementations:
Specific implementations might further define ways in which delivery context information might be accessed via application program interfaces or cached in data repositories.
Delivery context information may capture diverse aspects of an access mechanism, may be augmented or processed by different kinds of intermediaries, and may be used by different application components in an origin server or intermediary. This means delivery context has to be supported by many software components along the delivery path. It will not necessarily be the case that a single software component creates the whole delivery context, and another single component accepts it and adapts content accordingly.
From the perspective of the implementer, software components must be able to create a delivery context, augment an existing delivery context with their own characteristics, replace parts of a delivery context to reflect the possible adaptation capabilities of the component, and decompose a delivery context to extract the characteristics which will control their processing.
To date, the user agent, usually based on the client, has been the software component that has been responsible for constructing a request for some Web content, and has therefore also assumed responsibility for creating any client-related delivery context. However, with access mechanisms that may increasingly include several hardware or software components, a more flexible way of building the delivery context will be required.
For example, a mobile device may be temporarily within range of a local LAN which provides fast Internet access as well as connection to a nearby printer and a large screen. By interacting with their mobile device, the user may wish to deliver some Web content on the printer or the screen. The delivery context may include characteristics, or references to characteristics, contributed by several components. Hardware characteristics may be provided by the printer, the screen and the mobile device. Software characteristics may be provided by the mobile device's operating system, user agent, and local media handling capabilities. Network characteristics may be provided relating to the LAN connection. User preferences may be provided relating to the user experience of the content to be accessed.
As the range of characteristics made available through the delivery context grows, so the implementer of the content adaptation process requires better mechanisms to extract the relevant characteristics from the delivery context.
For example, if multiple overlapping characteristics exist within the delivery context, such as the pixel dimensions of the presentation spaces of each of the mobile device, the printer and the screen in the previous example, resolution rules or other mechanisms are required to determine which characteristics should be used.
The overall Architecture of the World Wide Web [WEB-arch] describes how information resources can be accessed and how multiple representations of the resource may be retrieved. This section looks at the role of delivery context within this overall architecture.
The role of the delivery context in accessing web-based content and applications is illustrated in the following diagrams.
Diagram 3.1: Client provides delivery context as well as request
The client which originates a request for some web content may also include some delivery context information which can help that request to be handled appropriately. In practice, the context information may be included as part of the request, or some (or all) of it may be supplied indirectly as a reference to information that is stored separately.
Delivery context information may also be used locally. For example, the amount of ambient light may be part of the delivery context information that is used to alter the brightness of a display. However, this use of delivery context is independent of the Web architecture.
Diagram 3.2: Server uses delivery context to adapt response
The server which responds to some request for web content may use delivery context information to adapt its response to better suit the needs of the client. Such server-side adaptation may include providing an appropriate data (MIME) type for the response, or an appropriate natural language in which to express text content, or even selecting appropriate application-specific data suited to the locale of the client.
Diagram 3.3: Intermediary may augment delivery context and adapt response
An intermediary in the path between client and server may also provide adaptation. The intermediary may modify the request, including providing new delivery context information, in such a way that the response can be adapted appropriately. For example, a transcoding proxy may offer to accept a media type not included in the original request. When the response is received by the proxy, that media type is adapted to one that is acceptable to the originator of the request.
In the most general situation, a sequence of intermediaries may provide additional delivery context information at different points in the request path from client to server and may modify the response in the response path between the server and the client. The response may be modified based on any delivery context information available at that point in the response path.
In some situations, an intermediary may block delivery context information from being passed further along the request path. For example, a phone may pass information about its location only as far as a mobile gateway, which does not make it available to the origin server.
The delivery context also has wider significance than its usage in developing adapted content. The application that runs on the user agent (typically the client device) can utilize the device and environment context information for providing contextual adaptation. One mechanism for accessing the system and environment context is the Delivery Context Interfaces (DCI) developed by the DI working group. Here, through the use of application scripts, a decision can be made as to whether adaptation can continue on the client side or new content is needed from server based on the current context.
Various approaches to defining delivery context, or at least some aspects of it, already exist. Indeed, the need to negotiate which version of a document should be delivered to a user was recognized in the early days of the Web [HTTPneg].
In this section, the main approaches that are already in use on the Web are reviewed.
The Hypertext Transport Protocol HTTP [HTTP] is the basis for most current Web-based information delivery. It defines a number of standard accept headers that can be used to match the capabilities of a requesting device (or, in particular, its user agent) to the information that is delivered from an origin server. Standard HTTP 1.1 accept headers include:
In addition to the accept headers, the User-Agent header usually contains a string giving information about the user agent. Typically this includes the name of the manufacturer, the version number and a name. For mobile devices, it often includes information about the device hardware and the browser being used. There are no standards about how user agent information is constructed. Nevertheless, sophisticated algorithms may use it to try to identify the device and browser software being used. A number of existing systems use this identification to access a repository of information about the capabilities of the device and browser. Adaptation of content for user experience can then be made based on knowledge of these capabilities.
While HTTP headers are currently the most widely used delivery context information, they are difficult to extend, and have (particularly in the case of the User-Agent header) free-form values that are difficult to interpret.
It is possible for a server to select content based simply on the HTTP header information. In HTTP 1.1 [HTTP] this is called server-driven negotiation.
In this case, the server determines which alternate to send to a user agent as a result of examining the user agent's request header fields. Currently HTTP 1.1 uses the following request-header fields, as described in the previous subsection, for server-driven negotiation: Accept, Accept-Charset, Accept-Encoding, Accept-Language. Each of these fields is referred to as a dimension of negotiation. In order to express user or browser preferences, the request-header fields may include an associated quality value for each dimension of negotiation.
For example the following header indicates that French resources are preferred to English resources.
Accept-Language: fr; q=1.0, en; q=0.5
There are some disadvantages associated with server-driven negotiation. Firstly the information sent in the request header does not give a complete description of the capabilities of the client. For example there is no way to distinguish between images intended for handheld computers from desktop computers if they both use the same MIME type. Secondly it is inefficient for a user agent to describe its full capabilities to a server for every request it makes. Finally server-driven negotiation causes problems for caches shared by multiple devices.
It is also possible within HTTP 1.1 to support agent-driven negotiation, in which the user agent is responsible for selecting the most appropriate content. The server initially responds with a list of available representations, which then allows the user agent to make another request for the preferred representation. However, this has the disadvantage of introducing additional delay through multiple request-response round trips.
The W3C has specified a data structure and sample vocabulary for profiles which can convey delivery context information. The current Composite Capabilities/Preferences Profile (CC/PP) [CCPP-struct-vocab] is based on the original XML serialized Resource Description Framework (RDF) [RDF].
The CC/PP structure is vocabulary independent and allows the use of one or more vocabularies which may be optionally described using RDF Schema. (See also the RDF Primer [RDF-primer] section 6.7 on "Describing Device Capabilities and User Preferences".)
As CC/PP is vocabulary neutral, it allows different vocabularies to be developed and implemented by communities involved in developing applications, devices and browsers. It also allows for the dynamic composition of a delivery context profile from fragments of capability information that may be distributed among multiple repositories on the web.
CC/PP is the preferred approach to communicating delivery context information between clients, intermediaries and origin servers. It is the basis for UAProf, which is currently used to express the capabilities of many mobile devices. There are a number of implementations available [CCPP-implem] which consume CC/PP profiles, and there is also a Java Community Process interface definition for profile consumers [JSR188].
The current CC/PP Recommendation [CCPP-struct-vocab] provides a structure and a sample vocabulary based on the version of RDF current during its development. It is expected to be brought up to date with the latest revisions of RDF [RDF-concepts] and RDF Schema [RDF-schema], and to be extended to include support for capabilities asserted by intermediate proxies and gateways. Further work is also required to specify a protocol for exchanging CC/PP profiles, and to specify how a profile should be processed and used within any mechanism for content adaptation. See Section 5 for further details of ongoing work.
The Open Mobile Alliance (OMA, formerly the WAP Forum) has defined a User Agent Profile [UAProf] as an implementation of CC/PP for WAP-enabled mobile terminals, providing convergence of mobile web technologies with those of the Web.
WAP 1.2.1 recommends transporting UAProf information over the Internet using the HTTP Extension Framework [HTTPex] which was originally suggested for CC/PP [CCPP-exchange]. WAP defined the WSP protocol, which includes a compressed encoding, for use between the phone and the gateway onto the Internet. Due to the lack of implementations of HTTPex, WAP 2.0 instead defined an extension of HTTP 1.1 as an Internet protocol (W-HTTP) that uses custom headers.
The WAP Forum also defined a UAProf vocabulary, based on CC/PP, that 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 and RDF Schema.
WURFL , [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 4500 variants of devices. Because WURFL is open source, anyone can correct device information, not just device manufacturers. WURFL provides its own XML format for device characteristics description.
In W3C recommendations, such as CSS and HTML, style markup can be made conditional on delivery context by using Media Queries [MQ]. These introduce another vocabulary for accessing device characteristics.
Media Queries build upon the use of 'media types' as defined in CSS2 [CSS2], which allow styles to be conditional on a number of named categories of device: aural, braille, embossed, handheld, print, projection, screen, tty and tv. In Media Queries, device characteristics ('media features') may be queried and combined using a restricted expression syntax. The style used to present an element of HTML, XHTML or XML can therefore be made conditional on the characteristics of the delivery device. By making use of the CSS 'display' property, it is also possible to conditionally include or exclude complete elements from the presentation.
In the future, it should therefore be possible to add device-dependent styling to common device-independent content, at least as far as the CSS media types and media features will allow.
Like CSS, Media Queries are typically expected to be processed directly in user agents, based on local delivery context information. However, they could also be fully or partially processed at servers or intermediaries in the response path, based on delivery context information passed as part of a request for content. This highlights the need for the vocabulary used for the device capabilities passed in the delivery context to correspond to the vocabulary used within Media Queries.
A further W3C standard, the Synchronized Multimedia Integration Language (SMIL) introduces yet another vocabulary for accessing a limited number of device characteristics.
SMIL 2.0 [SMIL] is defined as a set of markup modules that can be integrated into specific language profiles. In particular, it defines a BasicContentControl Module that defines certain system characteristics that may be used to control a SMIL presentation. These characteristics may be given dynamic values according to the runtime environment. Like Media Queries, they therefore allow a user agent that supports dynamic SMIL characteristics to access local delivery context information.
System test characteristics included as part of the SMIL BasicContentControl Module cover presentation-related capabilities such as screen size, network bandwidth, and text and audio captions, as well as system-related characteristics such as CPU and operating system identity.
The following approaches have been proposed, but have not been widely implemented to date.
Transparent Content Negotiation [TCN], was first proposed as an experimental protocol in RFC 2295.
Transparent negotiation uses both HTTP server-driven and agent-driven negotiation mechanisms (as described in Section 4.2), together with a caching proxy that supports content negotiation. The proxy requests a list of all available representations from the origin server using agent-driven negotiation, then selects the most appropriate and sends it to the client using server-driven negotiation. However, this technique has not been widely implemented.
The IETF Content Negotiation working group [Conneg] focused on defining the features which could form the basis for negotiation. In particular, in RFC 2506, a procedure was defined for registering Media Feature Tags in a central Internet Assigned Numbers Authority (IANA) registry.
A further result of the Conneg work was a proposal for combining Media Features Tags into Media Feature Sets [MFS]. In RFC 2533, a syntax for expressing Boolean combinations of features is proposed and an algorithm for feature set matching (see also [FSM]) is also described.
ISO/IEC is defining the MPEG-21 [MPEG-21] framework which is intended to support transparent use of multimedia resources across a wide range of networks and devices. The fundamental unit of distribution is the 'digital item', which is an abstraction for some multimedia content with associated data.
One aspect of the requirements for MPEG-21 is Digital Item Adaptation which is based on a Usage Environment Description (see section 4.7.2 in [MPEG-21-req]). It proposes the description of capabilities for at least the terminal, network, delivery, user, and natural environment, and notes the desirability of remaining compatible with other recommendations such as CC/PP and UAProf.
While existing techniques provide some basic support for delivery context information, there are a number of areas that remain to be addressed. The W3C Device Independence Working Group (DIWG) is chartered [DI-charter] to carry out further work on delivery context and its use in web authoring.
The W3C Delivery Context Workshop held in March 2002 [DCW] gave an opportunity for presentation and discussion about technologies associated with device independent delivery, and delivery context in particular. The workshop identified a number of areas relating to delivery context where further work was necessary.
For example, among some of the topics discussed were:
For further details see the position papers, presentations and workshop notes.
This remainder of this section summarizes the areas of ongoing work within DIWG and the issues that are currently being addressing.
The current W3C recommendation for representing delivery context information is CC/PP, as described in Section 4.3.
Some aspects of the original proposals of the CC/PP working group were omitted in the current recommendation due to lack of implementation experience. These include support in the profile for describing the capabilities of transcoding proxies, which may in some cases extend the effective capabilities of a device. For example, they may allow a wider range of image formats to be accepted in an HTTP response from a server, since the proxy can transcode them into an image format accepted by a particular device.
It has already been mentioned that a revised version of CC/PP is under consideration that would make fuller use of the latest version of RDF. In particular, RDF now supports the explicit association of data values with their data type. This has the potential to allow CC/PP profiles to be more self-describing, in that type information about capabilities would no longer need to be defined in an RDF schema that was separately conveyed to the profile consumer.
In order to implement the interoperable exchange of delivery context information, it is necessary to specify how the information is conveyed as part of a request protocol. Apart from the use of HTTP headers to express some limited aspects of delivery context as described earlier, no consensus has been reached on how more general delivery context information can be conveyed.
A proposal was made for a protocol for CC/PP based on the HTTP Extension Framework [CCPP-exchange], but in practice this framework has not been widely implemented.
UAProf [UAProf] has defined a protocol based on additional ad hoc HTTP header fields.
However, there is still a need to standardize an extensible way of conveying delivery context, beyond the existing header fields, as part of an HTTP 1.1 request.
Protocol design is non-trivial. Care must be taken, especially if it is to affect many web requests, not to introduce inefficiencies. For example, to minimize additional use of network bandwidth, a protocol should encourage optimizations such as indirect reference to static parts of the context information or caching of unchanging characteristics. A protocol should also allow intermediaries, if necessary, to access and augment the contextual information with minimal overhead.
Session-based management of context could be considered, complementing the widely implemented HTTP state management using cookies, as described in RFC 2965. If delivery context information were associated with a session, it might not be necessary to convey the full context with each request. Instead, it might be possible to simply notify changes from the previous context data.
Further work on CC/PP Protocol is included in the charter of the Device Independence Working Group [DI-charter]. This will focus on a protocol for use with conventional stateless HTTP requests. Work on session-based protocols is out of the current scope.
It is not sufficient simply to define how delivery context information can be conveyed as part of a communication protocol. For the end-to-end semantics of the delivery process to be well defined and predictable, it is also necessary to consider how the context information is resolved and made available to the adaptation or negotiation mechanisms at the different points in the delivery chain described in Section 3.
Profile information could be distributed across multiple locations on the web. It may not be consolidated and made available all in one place. For example, a hardware manufacturer and a software provider may make the static capabilities of their respective parts of an access mechanism available on their own websites, whereas network capabilities may depend on the routing of a particular request. So it should be possible to retrieve distributed capability information and compose or derive the delivery context at any appropriate point in the delivery path. To do this flexibly, a delivery context should be able to use combinations of characteristics from multiple vocabularies, or multiple versions of a single vocabulary, that relate to different aspects of an access mechanism. For example CC/PP uses XML namespaces to distinguish characteristics from different vocabularies.
Since a delivery context may be built from characteristics provided by different components along the delivery path, it should be possible to accumulate delivery context information provided by different components. The means of accumulation could simply consist of appending the information from different sources in separate profiles, or of combining them into a single profile. It should not be assumed that any particular component along the path is capable of resolving the information further.
Resolution rules can be used to describe how characteristics may default or override. However, if different rules are created for different characteristics, the complexity of the resolution process can quickly grow. Resolution mechanisms may be specific to each application, or application independent resolution mechanisms may be used for all applications that depend on the same profile. For example the UAProf standard specifies application independent resolution rules.
Processing rules are also necessary to define the behavior of processing sequences such as a client, an intermediary acting as a proxy and an origin server. Here the client device and the proxy may provide different versions of the same characteristics, so it is necessary to disambiguate. Similarly, there may be a need to deal with aggregated devices, such as connecting a phone and PDA in order to provide voice and text browsing. Here one of the devices may merge the profiles from the phone and the PDA in order to allow the server to provide a multimodal interface. In this case it is necessary to determine which of the client devices, and possibly which modality or other grouping on that device, provides a particular characteristic.
Delivery context characteristics must also fit into authoring and adaptation environments, and allow individual characteristics to be accessed as part of page adaptation on origin servers as well as by intermediaries and clients.
In DIWG, it is intended to cover CC/PP processing at the same time as work on CC/PP protocol, since the two are closely related in their implementation.
Delivery context information is expressed in terms of values of characteristics which may be drawn from, and are defined in, one or more vocabularies.
In the overview of existing and proposed approaches, it is clear that many groups have started to define vocabularies that could be used to express aspects of delivery context. For device capabilities alone, there are already Media Features defined in the IANA registry as part of the Conneg work, different versions of the UAProf vocabulary defined by the Open Mobile Alliance, Media Queries as part of CSS style, system characteristics in SMIL, and an example CC/PP vocabulary.
Vocabularies for delivery context characteristics need to be standardized so that authoring and adaptation processes can use them in a consistent fashion to select or generate suitable user experiences.
It is inevitable that vocabularies for characteristics will evolve through a number of different versions. It is also likely that they will need to incorporate characteristics that have been defined in other approaches for other purposes, as illustrated in the range of potential characteristics described in Section 1.1. There is a danger that vocabularies and their versions may proliferate so that the task of interpreting them and making appropriate adaptations to delivered content becomes unmanageable.
It should be possible to declare a set of characteristics as a vocabulary that can be combined with other vocabularies for other characteristics. By sharing sets of characteristics between vocabularies, it should be possible to minimize the number of different characteristics that might be introduced for essentially similar capabilities. CC/PP, by being based on RDF, naturally supports such definition and re-use.
It is preferable to re-use characteristics whenever possible during vocabulary definition. However, it may also be possible to separately identify equivalences between characteristics from different vocabularies at a later date. The Web Ontology Language [OWL] provides a means both for defining the properties and classes that might make up a vocabulary as well as making explicit the relationships, such as disjointness and equivalence, there might be between them.
Some of the markup languages referred to in Section 4 already provide mechanisms for authors to refer to delivery context characteristics when creating web pages. In particular, CSS Media Queries and SMIL introduce ways of referring to a limited set of characteristics. CSS is intended to be used for adding styling information to other markup languages, such as XHTML and SVG, and so allows delivery context dependent styling to be expressed in a uniform way for the languages which incorporate it, at least for the few characteristics it defines. The set of characteristics introduced by SMIL is also small, and defined in a way specific to that language.
In anticipation of the need to express content selection for web pages that is dependent on delivery context, a draft proposal has been produced by DIWG for a context-dependent way of expressing Content Selection [DI-sel]. In particular, this advocates the potential use of XPath or RDF Query to access delivery context information, using modular markup that could be incorporated in other languages such as Modular XHTML.
The Delivery Context Interfaces (DCI) work being developed by DIWG defines a platform independent API for accessing delivery context information. The interface allows mechanisms to both query and update properties. For dynamic properties, it is important to be able to respond to changes when they occur, consequently a mechanism to subscribe and unsubscribe to events is provided. The DCI is designed to allow for properties to be defined by different organizations. The Open Mobile Alliance (OMA) has developed a set of properties for describing static characteristics of mobile phones. Device vendors are expected to define additional properties for proprietary features.
A set of XHTML Document Profile Requirements were proposed in 1999 [XHTML-docprofile]. These could be seen as complementary to delivery context characteristics, in that they could potentially define document characteristics that would be required in order to successfully deliver a document.
This leads to considering the broader use of metadata, created as part of document authoring, as a means of guiding the adaptation of content for a particular delivery context. At the time of writing, W3C is about to hold a Workshop on Metadata for Content Adaptation to explore this topic further.
While it is not the purpose of this document to identify specific requirements, it is useful to collect together some remaining open issues, beyond the work described in the previous section.
It may be useful to identify the source of delivery context information provided by different components along the delivery path, and to extract the information from the delivery context provided by each source.
By identifying the source of some delivery context information, it may be possible to do a better job of adapting the content. For example, a request for printed output made via a phone may include device capabilities for the printer (so that the output can be formatted for it) as well as for the phone (so that any print control or error messages can be displayed on it). It is important that these can be distinguished and separately extracted.
In addition, it may be important for assessing the reliability of the delivery context information, or the trust to be placed in it, for its source to be identified.
If document metadata (as mentioned in Section 5.6), or some similar mechanism, is used to describe the capabilities required of the delivery device, there needs to be a way of matching this to the delivery context information so that appropriate content can be delivered.
With the modularization of markup languages such as XHTML, SVG, CSS and SMIL, a mechanism is also required for representing and negotiating which modules are supported by a user agent and which modules are required to successfully deliver a document. For example, the 3GPP specification for Packet Switched Streaming service [3GPP-PSS], which is based on SMIL, defines its own vocabulary for capability exchange based on UAProf and includes a means of enumerating supported SMIL modules.
Several techniques have been proposed to perform capability negotiation between devices: for example SyncML for data synchronization or the Wireless Village Initiative for instant messaging - both of these are now consolidated into the Open Mobile Alliance.
Since delivery context could be used to convey user-specific information, it is important to consider how much trust the user can place in how that information is handled. Ultimately this could extend to providing security measures for ensuring the privacy of sensitive information.
An early working draft of CC/PP Implementors Guide on Privacy and Protocols [CCPP-trust] includes a discussion on privacy issues within the CC/PP framework, including examples of how the recommendations of the Platform for Privacy Preferences Project [P3P] could be used with CC/PP. It also includes an Appendix on "Basic requirements for trust management frameworks".
Issues that relate to trust include:
Many of these issues are beyond the scope of device independence. If limited information about device and network capabilities can be freely shared, the user can benefit from receiving content better suited to the delivery device. This is the case currently, for example, in the use of HTTP header information. However, if such capability information is withheld, the user should still be provided with a functional user experience.
However, it is necessary to consider the potential misuse of any characteristics that are provided in good faith in order to achieve a better user experience, and to balance this against the benefits. Ultimately, the user should be given control over whether user experience-related characteristics are made available by a user agent as part of the delivery context. In addition, it may be necessary to include in the delivery context itself, or in the definition of its processing, rules that indicate what may or may not be changed or acted on by intermediaries.
This document has focused on delivery context in a traditional Web delivery environment. In other words, the focus has been on the conveying of delivery context information from a client to a server, via possible intermediaries, using HTTP.
However, the general principles may be applicable to other environments using other protocols. For example, Multimodal Interaction and Web Services use alternatives to, or extensions of, HTTP. However, they both have the need to describe the characteristics of the context into which they are delivering the results of web requests.
In particular, even if the details of conveying delivery context information in a particular protocol may differ, the representation of that information, and the vocabularies on which it depends, may be shared across many environments. The benefits of re-using the syntax and semantics of device and other delivery context characteristics in different environments are greater interoperability and reduced implementation costs.
Delivery context information may be useful across a wide range of distributed application domains, and not least for achieving device independence for the Web. In this domain, it provides the key information on which better adaptation of content across different access mechanisms must depend.
This document has provided an overview of progress in representing and using delivery context for this purpose. The W3C Device Independence Working Group is chartered to continue work on further topics in this area.
Members of the W3C Device Independence Working Group have helped develop this Working Group Note through their comments, proposals and discussions at teleconferences, face-to-face meetings and via the group discussion list.
At the time of publication, the principal and active members of the group were as follows:
The following were members of the group at earlier stages of its drafting:
Since the last version, the document underwent changes to reflect client and server side adaptation. The role of delivery context was clarified with regard to adaptation and content access. Diagram 3.1 was changed to reflect client side context access. An introduction to DCI work was provided. DCI was added as a possible candidate for device delivery context access mechanisms.