index.html 75.6 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Delivery Context Overview for Device Independence</title>
  <style type="text/css">
code { font-family: monospace; margin-left: 2em }
.ref { font-size: 80% }
.quote { margin-left: 5%; margin-right: 10% }
.definition { margin-left: 5%; margin-right: 10%; font-style: italic }
.diagram { text-align: center; font-size: 80%; font-weight: bold }
.changed {background-color: rgb(255, 255, 224)}
.deleted {background-color: rgb(240, 240, 240); text-decoration: line-through }
.comment {background-color: rgb(0, 204, 204)}
.pending {background-color: rgb(255, 224, 224)}
  </style>
  <link href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css"
  rel="stylesheet" type="text/css" />
</head>

<body xml:lang="en" lang="en">

<div class="head">
<a href="http://www.w3.org/"><img alt="W3C" height="48"
src="http://www.w3.org/Icons/w3c_home" width="72" /></a>

<h1>Delivery Context Overview for Device Independence</h1>

<h2>W3C Working Group Note 20 March 2006</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2006/NOTE-di-dco-20060320/">http://www.w3.org/TR/2006/NOTE-di-dco-20060320/</a></dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/di-dco/">http://www.w3.org/TR/di-dco/</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2005/NOTE-di-dco-20050118/">http://www.w3.org/TR/2005/NOTE-di-dco-20050118/</a></dd>
  <dt>Editors:</dt>
    <dd>Roger Gimson (HP)</dd>
    <dd>Rhys Lewis (Volantis Systems Ltd.)</dd>
    <dd>Sailesh Sathish (Nokia)</dd>
  <dt>Contributors:</dt>
    <dd>See <a href="#acknowledgements">Acknowledgements</a></dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
&#169; 2006 <a href="http://www.w3.org/"><acronym
title="World Wide Web Consortium">W3C</acronym></a><sup>&#174;</sup> (<a
href="http://www.csail.mit.edu/"><acronym
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
href="http://www.ercim.org/"><acronym
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>
</div>
<hr title="Separator for header" />

<h2 id="abstract">Abstract</h2>

<p>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.</p>

<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.</p>

<p>Details of the entire series of documents can be found on the <a
href="http://www.w3.org/2001/di/">W3C Device Independence Activity</a> home
page.</p>

<h2 id="status">Status of this Document</h2>

<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a>
at http://www.w3.org/TR/.</em></p>

<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.
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.</p>

<p>This document is one of a series produced by the <a
href="http://www.w3.org/2001/di/Group/">Device Independence Working
Group</a>(Member Only Link), part of the <a
href="http://www.w3.org/2001/di/">W3C Device Independence Activity</a>. The
DIWG activity statement can be seen at <a
href="http://www.w3.org/2001/di/Activity">http://www.w3.org/2001/di/Activity</a>.</p>

<p>Comments on this document can be sent to <a
href="mailto:www-di@w3.org">www-di@w3.org</a>, the public forum for
discussion of the W3C's work on Device Independence. To subscribe, send an
email to <a href="mailto:www-di-request@w3.org">www-di-request@w3.org</a>
with the word subscribe in the subject line (include the word unsubscribe if
you want to unsubscribe). The <a
href="http://lists.w3.org/Archives/Public/www-di/">archive</a> for the list
is accessible online.</p>

<p>This document was produced by a group operating under the <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February
2004 W3C Patent Policy</a>. This document is informative only. W3C
maintains a <a rel="disclosure"
href="http://www.w3.org/2004/05/di-charter-2004-06.html#ipr">public
list of any patent disclosures</a> 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 <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
Claim(s)</a> must disclose the information in accordance with <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
6 of the W3C Patent Policy</a>.</p>

<h2 id="contents">Table of Contents</h2>
<ul class="toc">
  <li><a href="#introduction">1 Introduction</a>
    <ul class="toc">
      <li><a href="#characteristics">1.1 Delivery context
      characteristics</a></li>
      <li><a href="#DIcontext">1.2 Delivery context for device
        independence</a></li>
    </ul>
  </li>
  <li><a href="#motivation">2 Motivation</a>
    <ul class="toc">
      <li><a href="#user">2.1 User perspective</a></li>
      <li><a href="#appdev">2.2 Application developer perspective</a></li>
      <li><a href="#implementer">2.3 Implementer perspective</a></li>
    </ul>
  </li>
  <li><a href="#role">3 Role in Web architecture</a></li>
  <li><a href="#existingapproaches">4 Existing approaches</a>
    <ul class="toc">
      <li><a href="#httpheaders">4.1 HTTP headers</a></li>
      <li><a href="#httpnegotiation">4.2 HTTP negotiation</a></li>
      <li><a href="#ccpp">4.3 CC/PP</a></li>
      <li><a href="#uaprof">4.4 UAProf</a></li>
      <li><a href="#wurfl">4.5 WURFL</a></li>
      <li><a href="#mediaqueries">4.6 Media Queries</a></li>
      <li><a href="#smil">4.7 SMIL</a></li>
      <li><a href="#otherapproaches">4.8 Other approaches</a>
        <ul class="toc">
          <li><a href="#tcn">4.8.1 TCN</a></li>
          <li><a href="#conneg">4.8.2 Conneg</a></li>
          <li><a href="#mediafeatures">4.8.3 Media Feature Sets</a></li>
          <li><a href="#mpeg-21">4.8.4 MPEG-21</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#DIWGwork">5 Areas of ongoing DIWG work</a>
    <ul class="toc">
      <li><a href="#representation">5.1 Delivery context
      representation</a></li>
      <li><a href="#protocol">5.2 Delivery context protocol</a></li>
      <li><a href="#processing">5.3 Delivery context processing</a></li>
      <li><a href="#vocabulary">5.4 Delivery context vocabulary</a></li>
      <li><a href="#access">5.5 Access to delivery context
      information</a></li>
      <li><a href="#metadata">5.6 Document metadata</a></li>
    </ul>
  </li>
  <li><a href="#issues">6 Open issues</a>
    <ul class="toc">
      <li><a href="#source">6.1 Source identification</a></li>
      <li><a href="#negotiation">6.2 Negotiation</a></li>
      <li><a href="#trust">6.3 Trust and privacy</a></li>
      <li><a href="#otherdomains">6.4 Use in other domains</a></li>
    </ul>
  </li>
  <li><a href="#conclusion">7 Conclusion</a></li>
  <li><br />
    <a href="#references">References</a></li>
  <li><br />
    <a href="#acknowledgements">Acknowledgements</a></li>
  <li><br />
    <a href="#diff">Changes since last version</a></li>
</ul>
<hr />
<!-- ===================================SECTION 1========================================== -->

<h2 id="introduction">1 Introduction</h2>

<p>The earlier <a href="http://www.w3.org/TR/di-princ/">Device Independence
Principles</a> document <span class="ref">[<a href="#DIP">DIP</a>]</span> 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 <a
href="http://www.w3.org/TR/di-gloss/">Glossary of Terms for Device
Independence</a> <span class="ref">[<a href="#GLOSS">GLOSS</a>]</span>. A
link is provided to the Glossary definition when a term is first used in the
following text.</p>

<p>The term <a
href="http://www.w3.org/TR/di-gloss/#def-delivery-context-v2">delivery
context</a>, as used when discussing web delivery (first introduced in <span
class="ref">[<a href="#DIP">DIP</a>]</span>), refers to:</p>

<p class="definition">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.</p>

<p>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.</p>

<p>Delivery context includes many factors that could have some effect on the
resultant experience of the delivered content by the user. Section <a
href="#characteristics">1.1</a> gives some illustrations of possible
characteristics of the delivery context. Section <a href="#DIcontext">1.2</a>
focuses on those characteristics that are particularly relevant to device
independence.</p>

<h3 id="characteristics">1.1 Delivery context characteristics</h3>

<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 <em>potential</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.</p>
<ul>
  <li>Interaction
    <ul>
      <li>presentation (output) modalities and their parameters</li>
      <li>capture (input) modalities and their parameters</li>
    </ul>
  </li>
  <li>User agent capabilities
    <ul>
      <li>processing (scripting etc) capabilities</li>
      <li>accepted and generated formats (e.g. MIME types)</li>
    </ul>
  </li>
  <li>Connection
    <ul>
      <li>bandwidth, latency</li>
      <li>networks and protocols</li>
      <li>information associated with telecommunications operators</li>
    </ul>
  </li>
  <li>Location
    <ul>
      <li>geographic coordinates</li>
      <li>proximity to other resources</li>
      <li>time of day</li>
    </ul>
  </li>
  <li>Locale
    <ul>
      <li>local language</li>
      <li>local time zone</li>
    </ul>
  </li>
  <li>Environment
    <ul>
      <li>temperature</li>
      <li>light</li>
      <li>noise</li>
    </ul>
  </li>
  <li>Level of discourse
    <ul>
      <li>literacy (text content complexity)</li>
      <li>verbosity (content detail)</li>
    </ul>
  </li>
  <li>Trust
    <ul>
      <li>privacy and security</li>
      <li>content restrictions</li>
    </ul>
  </li>
</ul>

<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 <a href="#trust">6.3 Trust and
Privacy</a>.</p>

<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.</p>

<p>Because of such variability, it is unlikely that any complete definition
of a <em>well-defined</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.</p>

<p class="diagram"><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" /> <br />
Diagram 1.1: Scope of delivery context characteristics</p>

<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.</p>

<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
<em>application-independent</em> way. This is particularly the case when
trying to provide general solutions to achieve device independence.</p>

<h3 id="DIcontext">1.2 Delivery context for device independence</h3>

<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.</p>

<p class="diagram"><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" /> <br />
Diagram 1.2: Scope of delivery context characteristics relevant to device
independence</p>

<p>The characteristics that are most relevant for achieving <em>device
independence</em> are those that characterize the capabilities of the <a
href="http://www.w3.org/TR/di-gloss/#def-access-mechanism">access
mechanism</a>, the capabilities of the network and some of the preferences of
the <a href="http://www.w3.org/TR/di-gloss/#def-user">user</a>. In
particular, a user may specify <a
href="http://www.w3.org/TR/di-gloss/#def-adaptation-preferences">adaptation
preferences</a> and <a
href="http://www.w3.org/TR/di-gloss/#def-rendering-preferences">rendering
preferences</a> that affect the <a
href="http://www.w3.org/TR/di-gloss/#def-user-experience">user experience</a>
they have of the delivered content (see <span class="ref">[<a
href="#DIP">DIP</a>]</span> for further details).</p>

<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 <a
href="http://www.w3.org/TR/di-gloss/#def-device">device</a>. The <a
href="http://www.w3.org/TR/di-gloss/#def-adaptation">adaptation</a> required
to achieve this may be performed by an <a
href="http://www.w3.org/TR/di-gloss/#def-origin-server">origin server</a>, by
an intermediary in the delivery path, or by a <a
href="http://www.w3.org/TR/di-gloss/#def-user-agent">user agent</a>.</p>

<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 <a
href="http://www.w3.org/TR/di-gloss/#def-functional-user-experience">functional
user experience</a> on that device, or may be further adapted to provide a <a
href="http://www.w3.org/TR/di-gloss/#def-harmonized-user-experience">harmonized
user experience</a> (as defined in <span class="ref">[<a
href="#DIP">DIP</a>]</span>). The possible adaptations that could be
performed on the available content can only be determined once the delivery
context information is known.</p>

<p>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 <a href="#access">5.5</a>.</p>

<p></p>
<!-- ===================================SECTION 2========================================== -->

<h2 id="motivation">2 Motivation</h2>

<p>In this section, motivation for more effective use of delivery context
information is provided from the perspectives of users, authors and
implementers.</p>

<h3 id="user">2.1 User perspective</h3>

<p>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.</p>

<p>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.</p>

<p>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 <a
href="http://www.w3.org/TR/di-gloss/#def-application-personalization">application
personalization</a> could also be transmitted as part of the delivery
context, but are outside the scope of this document since they are inherently
application-dependent.</p>

<p>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.</p>

<p>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 <a href="#trust">6.3</a>.</p>

<h3 id="appdev">2.2 Application developer perspective</h3>

<p>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.</p>

<p>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.</p>

<p>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 <span class="ref">[<a
href="#MQ">MQ</a>]</span>. Proposals to allow context-dependent content
selection are under development <span class="ref">[<a
href="#DI-sel">DI-sel</a>]</span>.</p>

<p>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.</p>

<p>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 <a
href="#vocabulary">5.4</a>.</p>

<h3 id="implementer">2.3 Implementer perspective</h3>

<p>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:</p>
<ul>
  <li>a data structure and vocabulary for exchanging delivery context
    information</li>
  <li>a protocol for conveying the delivery context information</li>
  <li>a processing model for handling the delivery context information</li>
</ul>

<p>Specific implementations might further define ways in which delivery
context information might be accessed via application program interfaces or
cached in data repositories.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>
<!-- ===================================SECTION 3========================================== -->

<h3 id="role">3 Role in Web architecture</h3>

<p>The overall Architecture of the World Wide Web <span class="ref">[<a
href="#WEB-arch">WEB-arch</a>]</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.</p>

<p>The role of the delivery context in accessing web-based content and
applications is illustrated in the following diagrams.</p>

<p class="diagram"><img
alt="Client shown as originating HTTP Request which may include delivery context"
src="client_ad.png" /> <br />
Diagram 3.1: Client provides delivery context as well as request</p>

<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.</p>

<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.</p>

<p class="diagram"><img
alt="Server shown as receiving HTTP Request and adapting HTTP Response depending on delivery context"
src="server.png" /> <br />
Diagram 3.2: Server uses delivery context to adapt response</p>

<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.</p>

<p class="diagram"><img
alt="Transcoding proxy shown as intermediary, forwarding HTTP Request and adapting HTTP Response"
src="intermediary.png" /> <br />
Diagram 3.3: Intermediary may augment delivery context and adapt response</p>

<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.</p>

<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.</p>

<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.</p>

<p>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.</p>

<p></p>
<!-- ===================================SECTION 4========================================== -->

<h2 id="existingapproaches">4 Existing approaches</h2>

<p>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 <span class="ref">[<a href="#HTTPneg">HTTPneg</a>]</span>.</p>

<p>In this section, the main approaches that are already in use on the Web
are reviewed.</p>

<h3 id="httpheaders">4.1 HTTP headers</h3>

<p>The Hypertext Transport Protocol HTTP <span class="ref">[<a
href="#HTTP">HTTP</a>]</span> 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:</p>
<ul>
  <li>Accept: media types (MIME types) accepted by the user agent</li>
  <li>Accept-Charset: character sets accepted by the user agent</li>
  <li>Accept-Encoding: preferred reply encoding (compression) for the user
    agent</li>
  <li>Accept-Language: natural languages preferred by the user</li>
</ul>

<p>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.</p>

<p>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.</p>

<h3 id="httpnegotiation">4.2 HTTP negotiation</h3>

<p>It is possible for a server to select content based simply on the HTTP
header information. In HTTP 1.1 <span class="ref">[<a
href="#HTTP">HTTP</a>]</span> this is called <i>server-driven
negotiation</i>.</p>

<p>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.</p>

<p>For example the following header indicates that French resources are
preferred to English resources.</p>

<p><code>Accept-Language: fr; q=1.0, en; q=0.5</code></p>

<p>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.</p>

<p>It is also possible within HTTP 1.1 to support <i>agent-driven
negotiation</i>, 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.</p>

<h3 id="ccpp">4.3 CC/PP</h3>

<p>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) <span class="ref">[<a
href="#CCPP-struct-vocab">CCPP-struct-vocab</a>]</span> is based on the
original XML serialized Resource Description Framework (RDF) <span
class="ref">[<a href="#RDF">RDF</a>]</span>.</p>

<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.
<span>(See also the RDF Primer <span class="ref">[<a
href="#RDF-primer">RDF-primer</a>]</span> section 6.7 on "Describing Device
Capabilities and User Preferences".)</span></p>

<p>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.</p>

<p>CC/PP is the preferred approach to communicating delivery context
information between clients, intermediaries and origin servers. It is the
basis for <a href="#uaprof">UAProf</a>, which is currently used to express
the capabilities of many mobile devices. There are a number of
implementations available <span class="ref">[<a
href="#CCPP-coordination">CCPP-implem</a>]</span> which consume CC/PP
profiles, and there is also a Java Community Process interface definition for
profile consumers <span class="ref">[<a href="#JSR188">JSR188</a>]</span>.</p>

<p>The current CC/PP Recommendation <span class="ref">[<a
href="#CCPP-struct-vocab">CCPP-struct-vocab</a>]</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 <span class="ref">[<a
href="#RDF-concepts">RDF-concepts</a>]</span> and RDF Schema <span
class="ref">[<a href="#RDF-schema">RDF-schema</a>]</span>, 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 <a
href="#DIWGwork">5</a> for further details of ongoing work.</p>

<h3 id="uaprof">4.4 UAProf</h3>

<p>The <a href="http://www.openmobilealliance.org/">Open Mobile Alliance</a>
(OMA, formerly the WAP Forum) has defined a User Agent Profile <span
class="ref">[<a href="#UAProf">UAProf</a>]</span> as an implementation of
CC/PP for WAP-enabled mobile terminals, providing convergence of mobile web
technologies with those of the Web.</p>

<p>WAP 1.2.1 recommends transporting UAProf information over the Internet
using the HTTP Extension Framework <span class="ref">[<a
href="#HTTPex">HTTPex</a>]</span> which was originally suggested for CC/PP
<span class="ref">[<a href="#CCPP-exchange">CCPP-exchange</a>]</span>. 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.</p>

<p>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.</p>

<h3 id="wurfl">4.5 WURFL</h3>

<p>WURFL , [<a href="#WURFL">WURFL</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.</p>

<h3 id="mediaqueries">4.6 Media Queries</h3>

<p>In W3C recommendations, such as CSS and HTML, style markup can be made
conditional on delivery context by using Media Queries <span class="ref">[<a
href="#MQ">MQ</a>]</span>. These introduce another vocabulary for accessing
device characteristics.</p>

<p>Media Queries build upon the use of 'media types' as defined in CSS2 <span
class="ref">[<a href="#CSS2">CSS2</a>]</span>, 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.</p>

<p>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.</p>

<p>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.</p>

<h3 id="smil">4.7 SMIL</h3>

<p>A further W3C standard, the Synchronized Multimedia Integration Language
(SMIL) introduces yet another vocabulary for accessing a limited number of
device characteristics.</p>

<p>SMIL 2.0 <span class="ref">[<a href="#SMIL">SMIL</a>]</span> 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.</p>

<p>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.</p>

<h3 id="otherapproaches">4.8 Other approaches</h3>

<p>The following approaches have been proposed, but have not been widely
implemented to date.</p>

<h4 id="tcn">4.8.1 TCN</h4>

<p>Transparent Content Negotiation <span class="ref">[<a
href="#TCN">TCN</a>]</span>, was first proposed as an experimental protocol
in <a href="http://www.ietf.org/rfc/rfc2295.txt">RFC 2295</a>.</p>

<p>Transparent negotiation uses both HTTP server-driven and agent-driven
negotiation mechanisms (as described in Section <a
href="#httpnegotiation">4.2</a>), 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.</p>

<h4 id="conneg">4.8.2 Conneg</h4>

<p>The IETF Content Negotiation working group <span class="ref">[<a
href="#Conneg">Conneg</a>]</span> focused on defining the features which
could form the basis for negotiation. In particular, in <a
href="http://www.ietf.org/rfc/rfc2506.txt">RFC 2506</a>, a procedure was
defined for registering Media Feature Tags in a central Internet Assigned
Numbers Authority (IANA) <a
href="http://www.iana.org/assignments/media-feature-tags">registry</a>.</p>

<h4 id="mediafeatures">4.8.3 Media Feature Sets</h4>

<p>A further result of the Conneg work was a proposal for combining Media
Features Tags into Media Feature Sets <span class="ref">[<a
href="#MFS">MFS</a>]</span>. In <a
href="http://www.ietf.org/rfc/rfc2533.txt">RFC 2533</a>, a syntax for
expressing Boolean combinations of features is proposed and an algorithm for
feature set matching (see also <span class="ref">[<a
href="#FSM">FSM</a>]</span>) is also described.</p>

<h4 id="mpeg-21">4.8.4 MPEG-21</h4>

<p>ISO/IEC is defining the MPEG-21 <span class="ref">[<a
href="#MPEG-21">MPEG-21</a>]</span> 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.</p>

<p>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 <span
class="ref">[<a href="#MPEG-21-req">MPEG-21-req</a>]</span>). 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.</p>
<!-- ===================================SECTION 5========================================== -->

<h2 id="DIWGwork">5 Areas of ongoing DIWG work</h2>

<p>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 <span class="ref">[<a
href="#DI-charter">DI-charter</a>]</span> to carry out further work on
delivery context and its use in web authoring.</p>

<p>The W3C Delivery Context Workshop held in March 2002 <span class="ref">[<a
href="#DCW">DCW</a>]</span> 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.</p>

<p>For example, among some of the topics discussed were:</p>
<ul>
  <li>device capability classes</li>
  <li>versioning and merging of profiles</li>
  <li>delivery context for multiple devices</li>
  <li>document profile relationship to delivery context</li>
  <li>standard vocabulary definition</li>
</ul>

<p>For further details see the <a
href="http://www.w3.org/2002/02/DIWS/submission/">position papers</a>, <a
href="http://www.w3.org/2002/02/DIWS/final.html">presentations</a> and <a
href="http://www.w3.org/2002/02/DIWS/notes.htm">workshop notes</a>.</p>

<p>This remainder of this section summarizes the areas of ongoing work within
DIWG and the issues that are currently being addressing.</p>

<h3 id="representation">5.1 Delivery context representation</h3>

<p>The current W3C recommendation for representing delivery context
information is CC/PP, as described in Section <a href="#ccpp">4.3</a>.</p>

<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.</p>

<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.</p>

<h3 id="protocol">5.2 Delivery context protocol</h3>

<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.</p>

<p>A proposal was made for a protocol for CC/PP based on the HTTP Extension
Framework <span class="ref">[<a
href="#CCPP-exchange">CCPP-exchange</a>]</span>, but in practice this
framework has not been widely implemented.</p>

<p>UAProf <span class="ref">[<a href="#UAProf">UAProf</a>]</span> has defined
a protocol based on additional <i>ad hoc</i> HTTP header fields.</p>

<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.</p>

<p>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.</p>

<p>Session-based management of context could be considered, complementing the
widely implemented HTTP state management using cookies, as described in <a
href="http://www.ietf.org/rfc/rfc2965.txt">RFC 2965</a>. 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.</p>

<p>Further work on CC/PP Protocol is included in the charter of the Device
Independence Working Group <span class="ref">[<a
href="#DI-charter">DI-charter</a>]</span>. This will focus on a protocol for
use with conventional stateless HTTP requests. Work on session-based
protocols is out of the current scope.</p>

<h3 id="processing">5.3 Delivery context processing</h3>

<p>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 <a href="#role">3</a>.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h3 id="vocabulary">5.4 Delivery context vocabulary</h3>

<p>Delivery context information is expressed in terms of values of
characteristics which may be drawn from, and are defined in, one or more
vocabularies.</p>

<p>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.</p>

<p>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.</p>

<p>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 <a href="#characteristics">1.1</a>. 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.</p>

<p>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.</p>

<p>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 <span class="ref">[<a
href="#OWL">OWL</a>]</span> 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.</p>

<h3 id="access">5.5 Access to delivery context information</h3>

<p>Some of the markup languages referred to in Section <a
href="#existingapproaches">4</a> 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.</p>

<p>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 <span
class="ref">[<a href="#DI-sel">DI-sel</a>]</span>. 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.</p>

<p>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.</p>

<p></p>

<h3 id="metadata">5.6 Document metadata</h3>

<p>A set of XHTML Document Profile Requirements were proposed in 1999 <span
class="ref">[<a href="#XHTML-docprofile">XHTML-docprofile</a>]</span>. 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.</p>

<p>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
<a href="http://www.w3.org/2004/06/DI-MCA-WS/">Workshop on Metadata for
Content Adaptation</a> to explore this topic further.</p>
<!-- ===================================SECTION 6========================================== -->

<h2 id="issues">6 Open issues</h2>

<p>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.</p>

<h3 id="source">6.1 Source identification</h3>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<h3 id="negotiation">6.2 Negotiation</h3>

<p>If document metadata (as mentioned in Section <a
href="#metadata">5.6</a>), 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.</p>

<p>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 <span class="ref">[<a
href="#_3GPP-PSS">3GPP-PSS</a>]</span>, which is based on SMIL, defines its
own vocabulary for capability exchange based on UAProf and includes a means
of enumerating supported SMIL modules.</p>

<p>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 <a href="http://www.openmobilealliance.org/">Open Mobile
Alliance</a>.</p>

<h3 id="trust">6.3 Trust and privacy</h3>

<p>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.</p>

<p>An early working draft of CC/PP Implementors Guide on Privacy and
Protocols <span class="ref">[<a href="#CCPP-trust">CCPP-trust</a>]</span>
includes a discussion on privacy issues within the CC/PP framework, including
examples of how the recommendations of the Platform for Privacy Preferences
Project <span class="ref">[<a href="#P3P">P3P</a>]</span> could be used with
CC/PP. It also includes an Appendix on "<a
href="http://www.w3.org/TR/2001/WD-CCPP-trust-20011220/#req-turst-frame">Basic
requirements for trust management frameworks</a>".</p>

<p>Issues that relate to trust include:</p>
<ul>
  <li>Identification, and possibly authentication, of the source of delivery
    context information</li>
  <li>Restriction of delivery context information, under user control, only
    to non-sensitive characteristics</li>
  <li>Release of delivery context information only to trusted applications or
    intermediaries</li>
  <li>Encryption and decryption of subsets of delivery context
  information</li>
</ul>

<p>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.</p>

<p>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.</p>

<h3 id="otherdomains">6.4 Use in other domains</h3>

<div>
<p>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.</p>

<p>However, the general principles may be applicable to other environments
using other protocols. For example, <a
href="http://www.w3.org/2002/mmi/">Multimodal Interaction</a> and <a
href="http://www.w3.org/2002/ws/">Web Services</a> 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.</p>

<p>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.</p>
</div>
<!-- ===================================SECTION 7========================================== -->

<h2 id="conclusion">7 Conclusion</h2>

<p>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.</p>

<p>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.</p>
<hr />
<!-- ===================================REFERENCES========================================== -->

<h2 id="references">References</h2>
<dl>
  <dt>[<a name="_3GPP-PSS" id="_3GPP-PSS">3GPP-PSS</a>]</dt>
    <dd><a
      href="ftp://ftp.3gpp.org/specs/2002-06/Rel-5/26_series/26234-510.zip">Transparent
      end-to-end packet switched streaming service (PSS) Protocols and codecs
      (Release 5)</a>, 3rd Generation Partnership Project TS 26.234 V5.1.0
      June 2002</dd>
  <dt>[<a name="CCPP-coordination"
  id="CCPP-coordination">CCPP-coordination</a>]</dt>
    <dd><a
      href="http://www.w3.org/TR/2001/NOTE-CCPP-COORDINATION-20011220/">CC/PP
      Implementors Guide: Harmonization with Existing Vocabularies and
      Content Transformation Heuristics</a>, W3C Note 20 December 2001<br />
      <i>For latest version see:</i>
    http://www.w3.org/TR/CCPP-COORDINATION/</dd>
  <dt>[<a name="CCPP-exchange" id="CCPP-exchange">CCPP-exchange</a>]</dt>
    <dd><a href="http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624">CC/PP
      exchange protocol based on HTTP Extension Framework</a>, W3C Note 24
      June 1999<br />
      <i>For latest version see:</i>
    http://www.w3.org/TR/NOTE-CCPPexchange</dd>
  <dt>[<a name="CCPP-ra" id="CCPP-ra">CCPP-ra</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/">Composite
      Capability/Preference Profiles: Requirements and Architecture</a>, W3C
      Working Draft 21 July 2000<br />
      <i>For latest version see:</i> http://www.w3.org/TR/CCPP-ra/</dd>
  <dt>[<a name="CCPP-struct-vocab"
  id="CCPP-struct-vocab">CCPP-struct-vocab</a>]</dt>
    <dd><a
      href="http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/">Composite
      Capability/Preference Profiles (CC/PP): Structure and Vocabularies
      1.0</a>, W3C Recommendation 15 January 2004<br />
      <i>For latest version see:</i>
    http://www.w3.org/TR/CCPP-struct-vocab/</dd>
  <dt>[<a name="CCPP-trust" id="CCPP-trust">CCPP-trust</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2001/WD-CCPP-trust-20011220/">CC/PP
      Implementors Guide: Privacy and Protocols</a>, W3C Working Draft 20
      December 2001<br />
      <i>For latest version see:</i> http://www.w3.org/TR/CCPP-trust</dd>
  <dt>[<a name="Conneg" id="Conneg">Conneg</a>]</dt>
    <dd><a
      href="http://www.ietf.org/html.charters/OLD/conneg-charter.html">IETF
      Content Negotiation Working Group</a>, concluded October 2000<br />
      http://www.ietf.org/html.charters/OLD/conneg-charter.html</dd>
  <dt>[<a name="CSS2" id="CSS2">CSS2</a>]</dt>
    <dd><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/">Cascading
      Style Sheets, level 2 CSS2 Specification</a>, W3C Recommendation 12 May
      1998<br />
      <i>For latest version see:</i> http://www.w3.org/TR/REC-CSS2</dd>
  <dt>[<a name="DCW" id="DCW">DCW</a>]</dt>
    <dd><a href="http://www.w3.org/2002/02/DIWS/">W3C Delivery Context
      Workshop</a>, INRIA Sophia-Antipolis, France, 4-5 March 2002<br />
      http://www.w3.org/2002/02/DIWS/</dd>
  <dt>[<a name="DI-charter" id="DI-charter">DI-charter</a>]</dt>
    <dd><a href="http://www.w3.org/2004/05/di-charter-2004-06.html">W3C
      Device Independence Working Group Charter</a> <br />
      http://www.w3.org/2004/05/di-charter-2004-06.html</dd>
  <dt>[<a name="DIP" id="DIP">DIP</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2003/NOTE-di-princ-20030901/">Device
      Independence Principles</a>, W3C Working Group Note 01 September
      2003<br />
      <i>For latest version see:</i> http://www.w3.org/TR/di-princ/</dd>
  <dt>[<a name="DI-sel" id="DI-sel">DI-sel</a>]</dt>
    <dd><a href="http://www.w3.org/TR/cselection/">Content Selection for
      Device Independence (DISelect) 1.0</a>, W3C Working Draft 11 June
      2004<br />
      <i>For latest version see:</i> http://www.w3.org/TR/cselection/</dd>
  <dt>[<a name="FSM" id="FSM">FSM</a>]</dt>
    <dd><a href="http://www.ninebynine.org/Software/Conneg-FSM/">Feature Set
      Matching</a>, sample software by Graham Klyne<br />
      http://www.ninebynine.org/Software/Conneg-FSM/</dd>
  <dt>[<a name="GLOSS" id="GLOSS">GLOSS</a>]</dt>
    <dd><a href="http://www.w3.org/TR/di-gloss/">Glossary of Terms for Device
      Independence</a>, W3C Working Draft January 2005 <br />
      <i>For latest version see:</i> http://www.w3.org/TR/di-gloss/</dd>
  <dt>[<a name="HTTP" id="HTTP">HTTP</a>]</dt>
    <dd><a href="http://www.w3.org/Protocols/rfc2616/rfc2616.html">Hypertext
      Transfer Protocol -- HTTP/1.1</a>, IETF RFC-2616 June 1999<br />
      http://www.w3.org/Protocols/rfc2616/rfc2616.html</dd>
  <dt>[<a name="HTTPex" id="HTTPex">HTTPex</a>]</dt>
    <dd><a href="http://www.ietf.org/rfc/rfc2774.txt">An HTTP Extension
      Framework</a>, IETF RFC-2774 February 2000<br />
      http://www.ietf.org/rfc/rfc2774.txt</dd>
  <dt>[<a name="HTTPneg" id="HTTPneg">HTTPneg</a>]</dt>
    <dd><a href="http://www.w3.org/Protocols/HTTP/Negotiation.html">HTTP
      Negotiation algorithm</a>, Tim Berners-Lee 1992<br />
      http://www.w3.org/Protocols/HTTP/Negotiation.html</dd>
  <dt>[<a name="JSR188" id="JSR188">JSR188</a>]</dt>
    <dd><a href="http://jcp.org/en/jsr/detail?id=188">JSR 188: CC/PP
      Processing</a>, Java Specification Request<br />
      http://jcp.org/en/jsr/detail?id=188</dd>
  <dt>[<a name="MFS" id="MFS">MFS</a>]</dt>
    <dd><a href="http://www.ietf.org/rfc/rfc2533.txt">A Syntax for Describing
      Media Feature Sets</a>, IETF RFC-2533 March 1999<br />
      http://www.ietf.org/rfc/rfc2533.txt</dd>
  <dt>[<a name="MPEG-21" id="MPEG-21">MPEG-21</a>]</dt>
    <dd><a
      href="http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm">MPEG-21
      Overview (v.5)</a>, ISO/IEC JTC1/SC29/WG11/N5231 October 2002</dd>
  <dt>[<a name="MPEG-21-req" id="MPEG-21-req">MPEG-21-req</a>]</dt>
    <dd><a
      href="http://www.chiariglione.org/mpeg/working_documents/mpeg-21/requirements/requirements.zip">MPEG-21
      Requirements v.2</a>, ISO/IEC JTC1/SC29/WG11 N6264 December 2003</dd>
  <dt>[<a name="MQ" id="MQ">MQ</a>]</dt>
    <dd><a
      href="http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708/">Media
      Queries</a>, W3C Candidate Recommendation 8 July 2002<br />
      <i>For latest version see:</i>
    http://www.w3.org/TR/css3-mediaqueries/</dd>
  <dt>[<a name="OWL" id="OWL">OWL</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2004/REC-owl-features-20040210/">OWL
      Web Ontology Language Overview</a>, W3C Recommendation 10 February
      2004<br />
      <i>For latest version see:</i> http://www.w3.org/TR/owl-features/</dd>
  <dt>[<a name="P3P" id="P3P">P3P</a>]</dt>
    <dd><a href="http://www.w3.org/P3P/">Platform for Privacy Preferences
      Project</a>, W3C Initiative<br />
      http://www.w3.org/P3P/</dd>
  <dt>[<a name="RDF" id="RDF">RDF</a>]</dt>
    <dd><a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">Resource
      Description Framework (RDF) Model and Syntax Specification</a>, W3C
      Recommendation 22 February 1999</dd>
  <dt>[<a name="RDF-concepts" id="RDF-concepts">RDF-concepts</a>]</dt>
    <dd><a
      href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/">Resource
      Description Framework (RDF): Concepts and Abstract Syntax</a>, W3C
      Recommendation 10 February 2004<br />
      <i>For latest version see:</i> http://www.w3.org/TR/rdf-concepts/</dd>
  <dt>[<a name="RDF-primer" id="RDF-primer">RDF-primer</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">RDF
      Primer</a>, W3C Recommendation 10 February 2004<br />
      <i>For latest version see:</i> http://www.w3.org/TR/rdf-primer/</dd>
  <dt>[<a name="RDF-schema" id="RDF-schema">RDF-schema</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210/">RDF
      Vocabulary Description Language 1.0: RDF Schema</a>, W3C Recommendation
      10 February 2004<br />
      <i>For latest version see:</i> http://www.w3.org/TR/rdf-schema/</dd>
  <dt>[<a name="SMIL" id="SMIL">SMIL</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2001/REC-smil20-20010807/">Synchronized
      Multimedia Integration Language (SMIL 2.0)</a>, W3C Recommendation 7
      August 2001<br />
      <i>For latest version see:</i> http://www.w3.org/TR/smil20</dd>
  <dt>[<a name="TCN" id="TCN">TCN</a>]</dt>
    <dd><a href="http://www.ietf.org/rfc/rfc2295.txt">Transparent Content
      Negotiation in HTTP</a>, IETF RFC-2295 March 1998<br />
      http://www.ietf.org/rfc/rfc2295.txt</dd>
  <dt>[<a name="UAProf" id="UAProf">UAProf</a>]</dt>
    <dd><a
      href="http://www.openmobilealliance.org/release_program/uap_v20.html">OMA
      User Agent Profile</a> <br />
      http://www.openmobilealliance.org/release_program/uap_v20.html</dd>
  <dt>[<a name="WAP2" id="WAP2">WAP2</a>]</dt>
    <dd><a href="http://www.wapforum.org/what/technical.htm">Wireless
      Application Protocol 2.0 specifications</a>, WAP Forum 31 July 2001<br
      />
      <i>For latest version see:</i>
      http://www.wapforum.org/what/technical.htm</dd>
  <dt>[<a name="WEB-arch" id="WEB-arch">WEB-arch</a>]</dt>
    <dd><a href="http://www.w3.org/TR/2004/WD-webarch-20040816/">Architecture
      of the World Wide Web, First Edition</a>, W3C Working Draft 16 August
      2004<br />
      <i>For latest version see:</i> http://www.w3.org/TR/webarch/</dd>
  <dt id="WURFL">[WURFL]</dt>
    <dd><a href="http://wurfl.sourceforge.net">WURFL Open Source
      Project.</a><i>See: http://wurfl.sourceforge.net/</i></dd>
  <dt>[<a name="XHTML-docprofile"
  id="XHTML-docprofile">XHTML-docprofile</a>]</dt>
    <dd><a href="http://www.w3.org/TR/1999/WD-xhtml-prof-req-19990906/">XHTML
      Document Profile Requirements</a>, W3C Working Draft 6 September
      1999<br />
      <i>For latest version see:</i> http://www.w3.org/TR/xhtml-prof-req</dd>
</dl>
<hr />
<!-- ===================================ACKNOWLEDGEMENTS========================================== -->

<h2 id="acknowledgements">Acknowledgements</h2>

<p>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.</p>

<p>At the time of publication, the principal and active members of the group
were as follows:</p>
<dl>
    <dd>Stephane Boyera (W3C)</dd>
    <dd>Roger Gimson (HP)</dd>
    <dd>Mark Butler (HP)</dd>
    <dd>Rotan Hanrahan (MobileAware Ltd)</dd>
    <dd>Kazuhiro Kitagawa (W3C)</dd>
    <dd>Augusto Aguilera (Boeing)</dd>
    <dd>Cedric Ulmer (SAP)</dd>
    <dd>Rhys Lewis (Volantis Systems Ltd)</dd>
    <dd>Roland Merrick (IBM)</dd>
    <dd>Andreas Schade (IBM)</dd>
    <dd>Gabriel Guillaume (France Telecom)</dd>
    <dd>Fabio Paterno (CNR--Instituto Elaborazione dell'Informazione)</dd>
    <dd>Sailesh Sathish (Nokia)</dd>
    <dd>Rafah Hosn (IBM)</dd>
    <dd>Matt Womer (France Telecom)</dd>
    <dd>Keith Waters (France Telecom)</dd>
    <dd>Max Froumentin (W3C)</dd>
</dl>

<p>The following were members of the group at earlier stages of its
drafting:</p>
<dl>
    <dd>Shahid Shoaib (NTT DoCoMo)</dd>
    <dd>Ryuji Tamagawa (Sky Co. Ltd.)</dd>
    <dd>Greg Ziebold (Sun Microsystems)</dd>
    <dd>Yoshihisa Gonno (Sony Corp)</dd>
    <dd>Luu Tran (Sun Microsystems)</dd>
    <dd>Michael Wasmund (IBM)</dd>
    <dd>Jason White (University of Melbourne)</dd>
    <dd>Masashi Morioka (NTT DoCoMo)Tayeb Lemlouma (INRIA)</dd>
    <dd>Guido Grassel (Nokia)</dd>
    <dd>Amy Yu (SAP AG)</dd>
    <dd>Candy Wong (NTT DoCoMo)</dd>
    <dd>Stan Wiechers (Merkwelt)</dd>
    <dd>Franklin Reynolds (Nokia)</dd>
    <dd>Markus Lauff (SAP AG)</dd>
    <dd>Steve Farowich (Boeing)</dd>
    <dd>Yasser AlSafadi (Philips Research)</dd>
    <dd>Abbie Barbir (Nortel Networks)</dd>
    <dd>Einar Breen (Adaptive Media)</dd>
    <dd>Shlomit Ritz Finkelstein (invited expert)</dd>
    <dd>Vidhya Golkar (Argogroup)</dd>
    <dd>Luo Haiping (Comverse)</dd>
    <dd>Eric Hsi (Philips Research)</dd>
    <dd>Lynda Jones (SHARE)</dd>
    <dd>William Loughborough (Smith-Kettlewell Institute)</dd>
    <dd>Stephane Maes (IBM)</dd>
    <dd>Kaori Nakai (NTT DoCoMo)</dd>
    <dd>Hidetaka Ohto (W3C/Panasonic)</dd>
    <dd>Garland Phillips (Motorola)</dd>
    <dd>Lalitha Suryanarayana (SBC Technology Resources)</dd>
    <dd>Yoshifumi Yonemoto (NTT DoCoMo)</dd>
</dl>

<h2 id="diff">Changes since last version</h2>

<p>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.</p>

<hr />
</body>
</html>