delete: <hr title="Separator for header">delete: <h2>delete: <a id="abstract">insert: <hr title="Separator for header" />insert: <h2 id="abstract">
Abstract delete: </a>
This document provides an overview of the role of delivery context in assisting achieving a device independent presentation for the 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.
delete: <h2>delete: <a id="status">insert: <p>
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. insert: </p>
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The A list of current W3C publications and the latest status of revision of this technical report can be found in the insert: <a href="http://www.w3.org/TR/">W3C technical reports index insert: </a>at http://www.w3.org/TR/. insert: </em>insert: </p>
insert: <p>
This document is a W3C Working Group Note. It represents the views of the W3C Device Independence Working Group at the time of publication. There are currently no plans to amend this document series is maintained at the W3C. delete: </em>delete: </p>delete: <p>further. Publication as a Working Group Note does not imply endorsement by the W3C Membership. This document is a public W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, replaced or made obsolete obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them this document as other than "work in progress". A list of current public W3C Working Drafts can be found at delete: <a href="http://www.w3.org/TR/">http://www.w3.org/TR delete: </a>. delete: </p>delete: <p>This is a working draft of a possible future W3C Note. work in progress.
This document is published as one of a series produced by the insert: <a
href="http://www.w3.org/2001/di/Group/">Device Independence Working Group insert: </a>(Member Only Link), part of the delete: <a href="http://www.w3.org/2001/di/Activity.html">insert: <a href="http://www.w3.org/2001/di/"> W3C Device Independence Activity by the Device Independence Working Group. It is a deliverable as defined in the delete: <a href="http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html">Charter delete: </a>of that group. . The DIWG activity statement can be seen at insert: <a
href="http://www.w3.org/2001/di/Activity">http://www.w3.org/2001/di/Activity insert: </a>.
Comments on this document may can be sent to insert: <a
href="mailto:www-di@w3.org">www-di@w3.org insert: </a>, the public delete: <a href="mailto:www-di@w3.org">www-di@w3.org delete: </a>mailing forum for discussion of the W3C's work on Device Independence. To subscribe, send an email to insert: <a href="mailto:www-di-request@w3.org">www-di-request@w3.org insert: </a>with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The insert: <a
href="http://lists.w3.org/Archives/Public/www-di/">archive insert: </a>for the list (archived at delete: <a href="http://lists.w3.org/Archives/Public/www-di/">http://lists.w3.org/Archives/Public/www-di/ delete: </a>). delete: </p>delete: <p>Patent disclosures relevant to this document may be found on the delete: <a href="http://www.w3.org/2001/di/Disclosures.html">WG patent disclosure page delete: </a>. delete: </p>delete: <h2>delete: <a id="contents">is accessible online. insert: </p>
The earlier insert: <a href="http://www.w3.org/TR/di-princ/"> Device Independence Principles insert: </a> 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 insert: <a
href="http://www.w3.org/TR/di-gloss/">Glossary of Terms for Device Independence insert: </a>insert: <span class="ref">[ insert: <a href="#GLOSS">GLOSS insert: </a>] insert: </span>. A link is provided to the Glossary definition when a term is first used in the following text.
The term delete: <a href="#def-delivery-context">delivery context delete: </a>was insert: <a
href="http://www.w3.org/TR/di-gloss/#def-delivery-context-v2">delivery context insert: </a>, as used when discussing web delivery (first introduced (in delete: <span class="ref">in insert: <span
class="ref"> [ DIP ] ) to refer to the ), refers to: insert: </p>
insert: <p class="definition">
A set of attributes that characterize the delivery environment. Among these attributes, the ones that are most relevant for achieving device independence are those that characterize the presentation characterizes the capabilities of the delete: <a href="#def-access-mechanism"> access mechanism delete: </a>, the delivery capabilities of the network and the presentation mechanism, the preferences of the user. delete: </p>delete: <p>Delivery context information is typically used to provide an appropriate format, styling or user and other aspect of some aspects of the context into which a web content that will make it suitable for the capabilities of a presentation device. The selection or adaptation required to achieve this may be performed by an origin server, by an intermediary in the delivery path, or by a user agent. delete: </p>delete: <p>From the point of view of device independence, the main concern is accurately reflecting the capabilities of the access mechanism and the presentation preferences of the user. Given appropriate information about the delivery context, the presentation of the delivered content can be selected or adapted to be functional on that device, or may be further customized to provide a better user experience (as defined in delete: <span class="ref">[ delete: <a href="#DIP">DIP delete: </a>] delete: </span>). The possible adaptations that could be performed on the available content can only be determined once the delivery context information is known. page is to be delivered.
In this document, techniques 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. insert: </p>
insert: <p>
Delivery context includes many factors that could have some effect on the resultant experience of the delivered content by the user. Section insert: <a
href="#characteristics">1.1 insert: </a>gives some illustrations of possible characteristics of the delivery context. Section insert: <a href="#DIcontext">1.2 insert: </a>focuses on those characteristics that are particularly relevant to device independence. insert: </p>
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 insert: <em>potential insert: </em>characteristics that might be expressed in the delivery context. However, the set of potential characteristics is open-ended, so this list is only illustrative. insert: </p>
insert: <ul>
insert: <li>
Interaction insert: <ul>
insert: <li>
presentation (output) modalities and their parameters insert: </li>
insert: <li>
capture (input) modalities and their parameters insert: </li>
accepted and generated formats (e.g. MIME types) insert: </li>
insert: </ul>
insert: </li>
insert: <li>
Connection insert: <ul>
insert: <li>
bandwidth, latency insert: </li>
insert: <li>
networks and protocols insert: </li>
insert: <li>
information associated with telecommunications operators insert: </li>
insert: </ul>
insert: </li>
insert: <li>
Location insert: <ul>
insert: <li>
geographic coordinates insert: </li>
insert: <li>
proximity to other resources insert: </li>
insert: <li>
time of day insert: </li>
insert: </ul>
insert: </li>
insert: <li>
Locale insert: <ul>
insert: <li>
local language insert: </li>
insert: <li>
local time zone insert: </li>
insert: </ul>
insert: </li>
insert: <li>
Environment insert: <ul>
insert: <li>
temperature insert: </li>
insert: <li>
light insert: </li>
insert: <li>
noise insert: </li>
insert: </ul>
insert: </li>
insert: <li>
Level of discourse insert: <ul>
insert: <li>
literacy (text content complexity) insert: </li>
insert: <li>
verbosity (content detail) insert: </li>
insert: </ul>
insert: </li>
insert: <li>
Trust insert: <ul>
insert: <li>
privacy and security insert: </li>
insert: <li>
content restrictions insert: </li>
insert: </ul>
insert: </li>
insert: </ul>
insert: <p>
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 insert: <a href="#trust">6.3 Trust and Privacy insert: </a>. insert: </p>
insert: <p>
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. insert: </p>
insert: <p>
Because of such variability, it is unlikely that any complete definition of a insert: <em>well-defined insert: </em>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. insert: </p>
insert: <p class="diagram">
insert: <img alt="Scope of delivery context characteristics"
longdesc="Concentric areas showing scope of delivery context characteristics, in which well-defined is a subset of potential, and application-independent is a subset of well-defined."
src="characteristics.png" />insert: <br /> Diagram 1.1: Scope of delivery context characteristics insert: </p>
insert: <p>
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. insert: </p>
insert: <p>
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 insert: <em>application-independent insert: </em>way. This is particularly the case when trying to provide general solutions to achieve device independence. insert: </p>
insert: <h3 id="DIcontext">
1.2 Delivery context for device independence insert: </h3>
insert: <p>
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. insert: </p>
insert: <p class="diagram">
insert: <img
alt="Scope of delivery context characteristics relevant to device independence"
longdesc="Concentric areas showing scope of device independent delivery context characteristics. Within application-independent delivery context characteristics are those relevant to device independence, and within those are a set of core presentation characteristics."
src="core.png" />insert: <br /> Diagram 1.2: Scope of delivery context characteristics relevant to device independence insert: </p>
insert: <p>
The characteristics that are most relevant for achieving insert: <em>device independence insert: </em>are those that characterize the capabilities of the insert: <a
href="http://www.w3.org/TR/di-gloss/#def-access-mechanism">access mechanism insert: </a>, the capabilities of the network and some of the preferences of the insert: <a href="http://www.w3.org/TR/di-gloss/#def-user">user insert: </a>. In particular, a user may specify insert: <a
href="http://www.w3.org/TR/di-gloss/#def-adaptation-preferences">adaptation preferences insert: </a>and insert: <a
href="http://www.w3.org/TR/di-gloss/#def-rendering-preferences">rendering preferences insert: </a>that affect the insert: <a
href="http://www.w3.org/TR/di-gloss/#def-user-experience">user experience insert: </a>they have of the delivered content (see insert: <span class="ref">[ insert: <a
href="#DIP">DIP insert: </a>] insert: </span>for further work are highlighted. delete: </p>delete: <h3 id="role">1.1 Role of delivery context delete: </h3>delete: <p>The role of the delivery context in accessing web-based content and applications is illustrated in the following diagrams. delete: </p>delete: <p class="diagram">delete: <img src="old_files/diagram1.gif" alt="Requestor (box) emits request (arrow) and also produces context (box)">delete: <br>Diagram 1: Requestor provides context as well as request delete: </p>delete: <p>The originator of a request for details). insert: </p>
insert: <p>
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 insert: <a
href="http://www.w3.org/TR/di-gloss/#def-device">device insert: </a>. The insert: <a
href="http://www.w3.org/TR/di-gloss/#def-adaptation">adaptation insert: </a>required to achieve this may also be performed by an insert: <a
href="http://www.w3.org/TR/di-gloss/#def-origin-server">origin server insert: </a>, by an intermediary in the delivery path, or by a insert: <a
href="http://www.w3.org/TR/di-gloss/#def-user-agent">user agent insert: </a>. insert: </p>
insert: <p>
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 insert: <a
href="http://www.w3.org/TR/di-gloss/#def-functional-user-experience">functional user experience insert: </a>on that device, or may be further adapted to provide a insert: <a
href="http://www.w3.org/TR/di-gloss/#def-harmonized-user-experience">harmonized user experience insert: </a>(as defined in insert: <span class="ref">[ insert: <a
href="#DIP">DIP insert: </a>] insert: </span>). The possible adaptations that could be performed on the available content can only be determined once the delivery context information is known. insert: </p>
insert: <p>
One of the goals of the work of the W3C Device Independence Working Group is to define some delivery context information which can help a set of insert: <em>core presentation characteristics insert: </em> that request to be handled appropriately. In the diagram, the context information is shown as a separate box. 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 will provide a well-defined, application-independent way of conveying delivery context information that is stored separately. delete: </p>delete: <p class="diagram">delete: <img src="old_files/diagram2.gif" alt="Adaptor (box) accepts response (arrow) and accesses context (box) then emits new response (arrow)">delete: <br>Diagram 2: Adaptor may change response based on context delete: </p>delete: <p>The response to some request for can be used when adapting web content may be adapted, based on the delivery context information available at that point in the delivery chain, to create a modified response. delete: </p>delete: <p class="diagram">delete: <img src="old_files/diagram3.gif" alt="Requestor (box) accepts request (arrow), produces context (box) and emits modified request (arrow), while associated adaptor (box) accepts response (arrow) and accesses same context (box) then emits new repsonse (arrow)">delete: <br>Diagram 3: Requestor and adaptor may act together as an intermediary delete: </p>delete: <p>A requestor and adaptor may act together as an element in the delivery path providing a specific part of the adaptation. The requestor may modify the request, including providing new 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. delete: </p>delete: <p class="diagram">delete: <img src="old_files/diagram4.gif" alt="Requestors and adaptors cascaded between client and server">delete: <br>Diagram 4: Client originates the request and server originates the response delete: </p>delete: <p>In the most general situation, a sequence of requestors may provide additional delivery context information at page presentations to a wide range of different points in the request path from client to server. Similarly, a sequence of adaptors 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. delete: </p>delete: <p>In some situations, delivery context information may only be available to a restricted set of adaptors. A requestor may block context information from being passed further along the request path, or may only make it available to an associated adaptor. 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. devices. This goal is described in more detail in Section insert: <a href="#vocabulary">5.4 insert: </a>.
2 Motivation
In this section, motivation for more effective use of delivery context information is provided from the perspectives of users, authors and implementers.
2.1 User perspective
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 attribute values inserted into an HTTP request header. But the user may need a mechanism to set preferred attribute values 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 an attribute a characteristic might be the screen size of a visual rendering device.
Other aspects of the delivery context, such as user preferences, will usually normally require user configuration. User preferences related to presentation user experience choices, may be managed by the user agent responsible for rendering some Web content. For example, a user may set their preferred language for delivered text within their browser options. User preferences related to insert: <a
href="http://www.w3.org/TR/di-gloss/#def-application-personalization"> application choices personalization insert: </a> could also be transmitted as part of the delivery context, but are outside the scope of this document. delete: </p>delete: <p>Since document since they are inherently application-dependent. insert: </p>
insert: <p>
Because the kind of content that may be is delivered may depend on the attributes 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 attributes. 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 attributes 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 later 6.3 .
2.2 Application developer perspective
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 this was proposed as part of XHTML under the name of Document Profiles delete: <span class="ref">[ delete: <a href="#XHTML-docprofile">XHTMLprof delete: </a>] delete: </span>, and context-dependent styling has been included in CSS under the name of Media Queries [ delete: <a href="#MQ">insert: <a
href="#MQ"> MQ insert: </a>] insert: </span>. Proposals to allow context-dependent content selection are under development insert: <span class="ref">[ insert: <a
href="#DI-sel">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 attributes conveyed by the information 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 delete: <a href="#vocabulary">later in Section insert: <a
href="#vocabulary">5.4 .
2.3 Implementer perspective
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:
a data format structure and vocabulary for exchanging delivery context information
a protocol for conveying the delivery context information
a processing model for handling the delivery context information
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 attributes, characteristics, replace parts of a delivery context to reflect the possible adaptation capabilities of the component, and decompose a delivery context to extract the attributes 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 attributes, characteristics, or references to attributes, characteristics, contributed by several components. Hardware attributes characteristics may be provided by the printer, the screen and the mobile device. Software attributes characteristics may be provided by the mobile device's operating system, user agent, and local media handling capabilities. Network attributes characteristics may be provided relating to the LAN connection. User preferences may be provided relating to the presentation user experience of the content to be accessed.
As the range of attributes characteristics made available through the delivery context grows, so the implementer of the content adaptation process requires better mechanisms to extract the relevant attributes characteristics from the delivery context.
For example, if multiple overlapping attributes 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 attributes characteristics should be used.
insert: <h3 id="role">
3 Role in Web architecture insert: </h3>
insert: <p>
The overall Architecture of the World Wide Web insert: <span class="ref">[ insert: <a
href="#WEB-arch">WEB-arch insert: </a>] insert: </span>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. insert: </p>
insert: <p>
The role of the delivery context in accessing web-based content and applications is illustrated in the following diagrams. insert: </p>
insert: <p class="diagram">
insert: <img
alt="Client shown as originating HTTP Request which may include delivery context"
src="client.png" />insert: <br /> Diagram 3.1: Client provides delivery context as well as request insert: </p>
insert: <p>
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. insert: </p>
insert: <p>
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. insert: </p>
insert: <p class="diagram">
insert: <img
alt="Server shown as receiving HTTP Request and adapting HTTP Response depending on delivery context"
src="server.png" />insert: <br /> Diagram 3.2: Server uses delivery context to adapt response insert: </p>
insert: <p>
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. insert: </p>
insert: <p class="diagram">
insert: <img
alt="Transcoding proxy shown as intermediary, forwarding HTTP Request and adapting HTTP Response"
src="intermediary.png" />insert: <br /> Diagram 3.3: Intermediary may augment delivery context and adapt response insert: </p>
insert: <p>
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. insert: </p>
insert: <p>
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. insert: </p>
insert: <p>
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. insert: </p>
3 4 Existing approaches
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.
3.1 4.1 HTTP headers
The Hypertext Transport Protocol HTTP [ delete: <a href="#HTTP">insert: <a
href="#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:
Accept: media types (MIME types) accepted by the user agent
Accept-Charset: charsets character sets accepted by the user agent
Accept-Encoding: content coding preferred reply encoding (compression) for the user agent
Accept-Language: natural languages preferred by the user
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 presentation 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.
3.2 4.2 HTTP negotiation
It is possible for a server to select content based simply on the HTTP header information. In HTTP 1.1 [ delete: <a href="#HTTP">insert: <a
href="#HTTP"> 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 fields, as described in the previous subsection, for server-driven negotiation: delete: </p>delete: <ul>delete: <li>Accept - the MIME types accepted by the user agent. delete: </li>delete: <li>Accept-Charset - the character set preferred by the user. delete: </li>delete: <li>Accept-Encoding - the preferred encoding for the user agent. delete: </li>delete: <li>Accept-Language - the language preferred by the user. delete: </li>delete: </ul>delete: <p>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. insert: </p>
insert: <p>
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.
3.3 4.3 CC/PP
The W3C delete: <a href="http://www.w3.org/Mobile/CCPP/">CC/PP Working Group delete: </a> has specified a data structure for profiles, called CC/PP (Composite Capabilities/ Preferences Profile), and sample vocabulary for profiles which can convey delivery context information. The current Composite Capabilities/Preferences Profile (CC/PP) insert: <span class="ref">[ insert: <a
href="#CCPP-struct-vocab">CCPP-struct-vocab insert: </a>] insert: </span> is based on the original XML serialized Resource Description Framework (RDF). This profile (RDF) insert: <span
class="ref">[ insert: <a href="#RDF">RDF insert: </a>] insert: </span>. insert: </p>
insert: <p>
The CC/PP structure is vocabulary independent and allows the use of one or more vocabularies which may be optionally described using RDF Schema. insert: <span>(See also the RDF Primer insert: <span class="ref">[ insert: <a
href="#RDF-primer">RDF-primer insert: </a>] insert: </span>section 6.7 on "Describing Device Capabilities and User Preferences".) insert: </span>insert: </p>
insert: <p>
As CC/PP is vocabulary neutral, it allows different vocabularies to be developed and implemented by application developer, device manufacturer and browser developer communities. delete: </p>delete: <p>CC/PP 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. Support insert: </p>
insert: <p>
CC/PP is the preferred approach to communicating delivery context information between clients, intermediaries and origin servers. It is the basis for insert: <a href="#uaprof">UAProf insert: </a>, which is currently used to express the capabilities of many mobile devices. There are a number of implementations available insert: <span class="ref">[ insert: <a
href="#CCPP-coordination">CCPP-implem insert: </a>] insert: </span>which consume CC/PP profiles, and there is also a Java Community Process interface definition for profile consumers insert: <span class="ref">[ insert: <a href="#JSR188">JSR188 insert: </a>] insert: </span>. insert: </p>
insert: <p>
The current CC/PP Recommendation insert: <span class="ref">[ insert: <a
href="#CCPP-struct-vocab">CCPP-struct-vocab insert: </a>] insert: </span>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 insert: <span class="ref">[ insert: <a
href="#RDF-concepts">RDF-concepts insert: </a>] insert: </span>and RDF Schema insert: <span
class="ref">[ insert: <a href="#RDF-schema">RDF-schema insert: </a>] insert: </span>, and to be extended to include support for capabilities asserted by intermediate proxies and gateways gateways. Further work is also enabled. delete: </p>delete: <p>The draft required to specify a protocol for exchanging CC/PP recommendation delete: <span class="ref">[ delete: <a href="#CCPP-struct-vocab">CCPP-struct-vocab delete: </a>] delete: </span>suggests a possible vocabulary, but does not define a protocol for exchanging profiles, and does not to specify how the a profile should be processed and used within any mechanism for content adaptation. delete: </p>delete: <p>There are two associated CC/PP Implementors Guides. The Guide on Privacy and Protocols delete: <span class="ref">[ delete: <a href="#CCPP-trust">CCPP-trust delete: </a>] delete: </span>discusses protocol issues as well as the way in which the privacy of profiles could be protected, including the use of mechanisms such as those defined by P3P delete: <span class="ref">[ delete: <a href="#P3P">P3P delete: </a>] delete: </span>. The Guide on Harmonizing with Existing Vocabularies and Content Transformation Heuristics delete: <span class="ref">[ delete: <a href="#CCPP-coordination">CCPP-coordination delete: </a>] delete: </span>discusses how different vocabularies could fit within the CC/PP framework and suggests some approaches to content adaptation. delete: </p>delete: <p>CC/PP is the preferred approach to communicating delivery context information between clients, intermediaries and origin servers. Work on its definition and implementation is continuing both in W3C and in the Java Community Process delete: <span class="ref">[ delete: <a href="#JSR188">JSR188 delete: </a>] delete: </span>. See Section insert: <a
href="#DIWGwork">5 insert: </a>for further details of ongoing work.
3.4 4.4 UAProf
The insert: <a href="http://www.openmobilealliance.org/"> Open Mobile Alliance (formerly insert: </a>(OMA, formerly the WAP Forum) has defined a User Agent Profile delete: <span class="ref">insert: <span
class="ref"> [ UAProf ] as an implementation of CC/PP for WAP-enabled mobile terminals, providing convergence of mobile web technologies with that of the classic web. those of the Web.
WAP 1.2.1 recommends transporting UAProf information over the Internet using the HTTP Extension Framework [ delete: <a href="#HTTPex">insert: <a
href="#HTTPex"> 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 defines defined an extension of HTTP 1.1 as an Internet protocol (W-HTTP) that uses custom headers.
The WAP Forum has also defined a profile vocabulary UAProf vocabulary, based on CC/PP, that includes assertions regarding the hardware and software characteristics and as well as WAP specific features of the mobile terminal and associated transport network capabilities. delete: </p>delete: <p>Vendors of WAP proxies and browsers are beginning to offer commercial implementations of network. Subsequent updating, to UAProf and the delete: <a href="http://www.3gpp.org/">3GPP delete: </a>Mobile Execution Environment (MExE) group V2.0, by OMA has adopted the UAProf - CC/PP framework for MExE terminals. based the definition on the latest version of RDF and RDF Schema. insert: </p>
insert: <h3 id="wurfl">
4.5 WURFL insert: </h3>
insert: <p>
WURFL , [ insert: <a href="#WURFL">WURFL insert: </a>], 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.
3.5 4.6 Media Queries
Within In W3C standards recommendations, such as CSS and HTML, style markup can be made conditional on delivery context by using Media Queries [ delete: <a href="#MQ">insert: <a
href="#MQ"> MQ ] . These introduce another vocabulary for accessing device attributes. characteristics.
Media Queries build upon the use of 'media types' as defined in CSS2 delete: <span class="ref">insert: <span
class="ref"> [ 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 attributes 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 attributes 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.
3.6 4.7 SMIL
A further W3C standard, the Synchronized Multimedia Integration Language (SMIL) introduces yet another vocabulary for accessing a limited number of device attributes. 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 attributes characteristics that may be used to control a SMIL presentation. These attributes characteristics may be given dynamic values according to the runtime environment. Like Media Queries, they therefore allow a user agent that supports dynamic SMIL attributes characteristics to access local delivery context information.
System test attributes 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 attributes characteristics such as CPU and operating system identity.
4.8 Other proposed approaches delete: </h2>insert: </h3>
The following approaches have been proposed, but have not been widely implemented to date.
delete: <h3 id="tcn">4.1 insert: <h4 id="tcn">
4.8.1 TCN delete: </h3>insert: </h4>
Transparent Content Negotiation [ delete: <a href="#TCN">insert: <a
href="#TCN"> 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 delete: <a href="#negotiation">above in Section insert: <a
href="#httpnegotiation">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 send sends it to the client using server-driven negotiation. However, this technique has not been widely implemented.
The IETF Content Negotiation working group [ delete: <a href="#Conneg">insert: <a
href="#Conneg"> Conneg ] focused on defining the features which could form the basis for negotiation. In particular, in delete: <a href="http://www.ietf.org/rfc/rfc2506.txt">insert: <a
href="http://www.ietf.org/rfc/rfc2506.txt"> RFC 2506 , a procedure was defined for registering Media Feature Tags in a central Internet Assigned Numbers Authority (IANA) delete: <a href="http://www.iana.org/assignments/media-feature-tags">insert: <a
href="http://www.iana.org/assignments/media-feature-tags"> registry .
4.8.3 Media Feature Sets delete: </h3>insert: </h4>
A further result of the Conneg work was a proposal for combining Media Features Tags into Media Feature Sets [ delete: <a href="#MFS">insert: <a
href="#MFS"> MFS ] . In delete: <a href="http://www.ietf.org/rfc/rfc2533.txt">insert: <a
href="http://www.ietf.org/rfc/rfc2533.txt"> RFC 2533 , a syntax for expressing Boolean combinations of features is proposed and an algorithm for feature set matching (see also [ delete: <a href="#FSM">insert: <a
href="#FSM"> FSM ] ) is also described.
delete: <h3 id="docprofiles">4.4 Document Profiles delete: </h3>delete: <p>A set of XHTML Document Profile Requirements were proposed in 1999 delete: <span class="ref">[ delete: <a href="#XHTML-docprofile">XHTML-docprofile delete: </a>] delete: </span>. These could be seen as complementary to device attributes, in that they could define attributes that would be required of the device in order to successfully deliver a document. delete: </p>delete: <h3 id="opes">4.5 OPES delete: </h3>delete: <p>A proposed new architecture for Open Pluggable Edge Services (OPES) is being developed within IETF delete: <span class="ref">[ delete: <a href="#OPES">OPES delete: </a>] delete: </span>. This provides the means for a server to delegate the content adaptation to an intermediary in such a way that it does not break the end-to-end model of the internet. Furthermore, the intermediary may make use of remote services to carry out the adaptation. The OPES architecture requires extensions to the HTTP protocol that allow the server to authorize and specify such transformations. OPES does not set out new proposals for representing delivery context, but is concerned with ways in which the context may relate to, or be used to control, adaptation services. delete: </p>delete: <h3 id="mpeg-21">4.6 insert: <h4 id="mpeg-21">
4.8.4 MPEG-21 delete: </h3>insert: </h4>
ISO/IEC is defining the MPEG-21 [ delete: <a href="#MPEG-21">insert: <a
href="#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 delete: <span class="ref">which is based on a Usage Environment Description (see section 4.7.2 in insert: <span
class="ref"> [ delete: <a href="#MPEG-21-DIA">MPEG-21-DIA insert: <a href="#MPEG-21-req">MPEG-21-req ] which is based on descriptions of the environment (including delivery context) and adaptability of the content. ). It includes the definition of vocabularies for content preferences, presentation preferences, terminal proposes the description of capabilities and network characteristics. delete: </p>delete: <h2 id="further">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. insert: </p>
insert: <h2 id="DIWGwork">
5 Further developments Areas of ongoing DIWG work
While existing techniques provide some basic support for delivery context information, there are a number of issues areas that remain to be addressed. This section summarizes some that have been raised to date. delete: </p>delete: <h3 id="fromdip">5.1 From The W3C Device Independence Principles delete: </h3>delete: <p>Two specific principles relating to delivery context were proposed in the Device Independence Principles Working Group (DIWG) is chartered [ delete: <a href="#DIP">DIP insert: <a
href="#DI-charter">DI-charter ] . delete: </p>delete: <div class="quote">delete: <p>delete: <a href="http://www.w3.org/TR/2001/WD-di-princ-20010918/#DIP-6">DIP-6 delete: </a>: The user agent should be able to associate the characteristics of the delivery context with a request of a particular Web page identifier. delete: </p>delete: <p>delete: <a href="http://www.w3.org/TR/2001/WD-di-princ-20010918/#DIP-7">DIP-7 delete: </a>: It should be possible for a user to provide or update any presentation preferences as part of the delivery context. delete: </p>delete: </div>delete: <p>In addition, in delete: <a href="http://www.w3.org/TR/2001/WD-di-princ-20010918/#section-FurtherContext">Section 3.2 delete: </a>, an area of to carry out further work was identified. delete: </p>delete: <div class="quote">delete: <p>For device independence to become widely supported, it will be necessary to indicate how the transition can be made from existing widely supported techniques of representing the delivery context towards future, more complete, proposals such as CC/PP. delete: </p>delete: <p>At a more implementation-specific level, this document has shown the delivery context being associated with a request for a Web page. There are several possibilities here. It is not necessary that the whole context is sent with each request. It could be that only a reference to the context is sent. Or that the context is managed on a session basis, or based on profiles stored elsewhere. delete: </p>delete: <p>CC/PP provides a possible representation for conveying delivery context information. However, the way in which the delivery context should be generated by the access mechanism (user agent) and the interpretation of the delivery context by the server (and possibly also by intermediate proxies) will need further recommendations to be developed. Ways of conveying the delivery context in device independent ways using existing techniques, prior to CC/PP becoming widely adopted, should also be considered. delete: </p>delete: </div>delete: <h3 id="fromdcw">5.2 From Delivery Context Workshop delete: </h3>delivery context and its use in web authoring. insert: </p>
The W3C Delivery Context Workshop held in March 2002 [ delete: <a href="#DCW">insert: <a
href="#DCW"> 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:
device capability classes
versioning and merging of profiles
delivery context for multiple devices
document profile relationship to delivery context
standard vocabulary definition
For further details see the delete: <a href="http://www.w3.org/2002/02/DIWS/submission/">insert: <a
href="http://www.w3.org/2002/02/DIWS/submission/"> position papers , delete: <a href="http://www.w3.org/2002/02/DIWS/final.html">insert: <a
href="http://www.w3.org/2002/02/DIWS/final.html"> presentations and insert: <a
href="http://www.w3.org/2002/02/DIWS/notes.htm"> workshop delete: <a href="http://www.w3.org/2002/02/DIWS/notes.htm"> notes .
delete: <h2 id="issues">6 Collected insert: <p>
This remainder of this section summarizes the areas of ongoing work within DIWG and the issues delete: </h2>delete: <p>While that are currently being addressing. insert: </p>
insert: <h3 id="representation">
5.1 Delivery context representation insert: </h3>
insert: <p>
The current W3C recommendation for representing delivery context information is CC/PP, as described in Section insert: <a href="#ccpp">4.3 insert: </a>. insert: </p>
insert: <p>
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. insert: </p>
insert: <p>
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. insert: </p>
insert: <h3 id="protocol">
5.2 Delivery context protocol insert: </h3>
insert: <p>
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. insert: </p>
insert: <p>
A proposal was made for a protocol for CC/PP based on the HTTP Extension Framework insert: <span class="ref">[ insert: <a
href="#CCPP-exchange">CCPP-exchange insert: </a>] insert: </span>, but in practice this framework has not the purpose of this document to identify specific requirements, been widely implemented. insert: </p>
insert: <p>
UAProf insert: <span class="ref">[ insert: <a href="#UAProf">UAProf insert: </a>] insert: </span>has defined a protocol based on additional insert: <i>ad hoc insert: </i>HTTP header fields. insert: </p>
insert: <p>
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. insert: </p>
insert: <p>
Protocol design is non-trivial. Care must be taken, especially if it is useful to collect together open issues. delete: </p>delete: <h
