Copyright© 2006W3C® (MIT,ERCIM,Keio), All Rights Reserved. W3Cliability,trademarkanddocumentuse rules apply.
This document provides an overview of the role of delivery context inachieving a device independent Web. It describes the kind of information thatmay be included in the delivery context, and how it may be used. It surveyscurrent techniques for conveying delivery context information, and identifiesfurther developments that would enhance the ability to adapt content fordifferent access mechanisms.
This document is one of a series produced by the W3C Device IndependenceWorking Group. Other documents in the series address the implementation ofsolutions to the requirements raised here. For example, there are documentsin the series reviewing current techniques that can be used to address theserequirements and exploring how future versions of existing W3C specificationscan provide solutions.
Details of the entire series of documents can be found on theW3C Device Independence Activity homepage.
This section describes the status of this document at the time of itspublication. Other documents may supersede this document. A list of currentW3C publications and the latest revision of this technical report can befound in theW3C technical reports indexat http://www.w3.org/TR/.
This document is a W3C Working Group Note. It represents the views of theW3C Device Independence Working Group at the time of publication. The document may be updated as new technologies related to the deliverymaxf context emerge or mature. Publication as a WorkingGroup Note does not imply endorsement by the W3C Membership. This is a draftdocument and may be updated, replaced or obsoleted by other documents at anytime. It is inappropriate to cite this document as other than work inprogress.
This document is one of a series produced by theDevice Independence WorkingGroup(Member Only Link), part of theW3C Device Independence Activity. TheDIWG activity statement can be seen athttp://www.w3.org/2001/di/Activity.
Comments on this document can be sent towww-di@w3.org, the public forum fordiscussion of the W3C's work on Device Independence. To subscribe, send anemail towww-di-request@w3.orgwith the word subscribe in the subject line (include the word unsubscribe ifyou want to unsubscribe). Thearchive for the listis accessible online.
This document was produced by a group operating under the5 February2004 W3C Patent Policy. This document is informative only. W3Cmaintains apubliclist of any patent disclosures made in connection with thedeliverables of the group; that page also includes instructions fordisclosing a patent. An individual who has actual knowledge of a patentwhich the individual believes containsEssentialClaim(s) must disclose the information in accordance withsection6 of the W3C Patent Policy.
The earlierDevice IndependencePrinciples document[DIP] setout a number of principles that can lead to greater device independence indelivering Web content and applications. Terms from this document, and othersrelated to device independence, are collected in theGlossary of Terms for DeviceIndependence[GLOSS]. Alink is provided to the Glossary definition when a term is first used in thefollowing text.
The termdeliverycontext, as used when discussing web delivery (first introduced in
A set of attributes that characterizes the capabilitiesof the access mechanism, the preferences of the user and other aspects of thecontext into which a web page is to be delivered.
In this document, the kind of information that may relate to the deliverycontext is described. The role of delivery context and adaptation in Webarchitecture is illustrated. Techniques for representing, conveying andprocessing delivery context are considered. Existing technologies thataddress these needs are reviewed. Areas that are under development by the W3CDevice Independence Working Group to address remaining needs are outlined.
Delivery context includes many factors that could have some effect on theresultant experience of the delivered content by the user. Section1.1 gives some illustrations of possiblecharacteristics of the delivery context. Section1.2focuses on those characteristics that are particularly relevant to deviceindependence.
There are many aspects of the delivery context that may influence whichrepresentation of some Web content is best delivered in response to arequest. In this section, we hint at the range ofpotentialcharacteristics that might be expressed in the delivery context. However, theset of potential characteristics is open-ended, so this list is onlyillustrative.
It is worth noting here that some of these characteristics could beconsidered as conveying sensitive information. Issues associated with privacyand trust are considered outside the scope of this particular note. Some ofthe challenges are discussed in6.3 Trust andPrivacy.
Some of the above characteristics may be intrinsic to, or can be evaluatedby, the delivery device; others may be set, or overridden, by the user. Somecharacteristics may stay fixed for long periods (such as the communicationsprotocols supported by the device); others may vary from one moment to thenext (such as geographic coordinates, or temperature). Any particular devicewill only support a subset of all possible characteristics, though thatsubset may change over time.
Because of such variability, it is unlikely that any complete definitionof awell-defined set of delivery context characteristics can exist.However, to allow for the evolution of a set of characteristics that can beof practical use in delivering appropriate content across a wide range ofcontexts, it is important that definitions of well-defined characteristicsfor subsets of the context can be re-used.
Diagram 1.1: Scope of delivery context characteristics
In some situations, there may be delivery context characteristics that arespecific to a particular application. However, many characteristics may beuseful to many applications. If each application were to define a differentrepresentation for its delivery context characteristics, it would requireeach delivery device to maintain delivery context information on aper-application level. Applications would need to know about devices, anddevices would need to know about applications. This goes against the 'networkeffect' that the Web encourages, whereby Web content and applications, andthe delivery devices use to access them, can be developed independently butin a mutually reinforcing manner.
For the remainder of this Note, we will focus on the issues that must beaddressed when defining and sharing delivery context information in anapplication-independent way. This is particularly the case whentrying to provide general solutions to achieve device independence.
Within the set of well-defined, application-independent delivery contextcharacteristics, an important subset are those that may help deliver webcontent more effectively across a wide range of delivery devices.
Diagram 1.2: Scope of delivery context characteristics relevant to deviceindependence
The characteristics that are most relevant for achievingdeviceindependence are those that characterize the capabilities of theaccessmechanism, the capabilities of the network and some of the preferences oftheuser. Inparticular, a user may specifyadaptationpreferences andrenderingpreferences that affect theuser experiencethey have of the delivered content (see[DIP] for further details).
For device independence, delivery context information is typically used toprovide an appropriate format, styling or other aspect of some web contentthat will make it suitable for the capabilities of a deliverydevice. Theadaptation requiredto achieve this may be performed by anorigin server, byan intermediary in the delivery path, or by auser agent.
From the point of view of device independence, the main concern isaccurately reflecting the capabilities of the access mechanism and thepreferences of the user. Given appropriate information about the deliverycontext, the delivered content can be adapted to provide afunctionaluser experience on that device, or may be further adapted to provide aharmonizeduser experience (as defined in[DIP]). The possible adaptations that could beperformed on the available content can only be determined once the deliverycontext information is known.
The W3C Device Independence Group is defining a set of specificationsrelated to the use of delivery context for delivering and running adaptedcontent accross a wide range of devices. One activity is the Delivery ContextInterfaces work that aims to provide a platform independent API for accessingdelivery context information that can be used during both server-side andclient-side content adaptation. This goal is described in more details insection5.5.
In this section, motivation for more effective use of delivery contextinformation is provided from the perspectives of users, authors andimplementers.
From the perspective of the user, the technology for conveying deliverycontext information is largely invisible. For example, a user is not usuallyaware of the values inserted into an HTTP request header. But the user mayneed a mechanism to set preferred delivery context characteristics whennecessary.
Some aspects of the delivery context, such as the underlying capabilitiesof the access mechanism, can be set automatically by software throughinternal configuration parameters. An example of such a characteristic mightbe the screen size of a visual rendering device.
Other aspects of the delivery context, such as user preferences, willnormally require user configuration. User preferences related to userexperience choices, may be managed by the user agent responsible forrendering some Web content. User preferences related toapplicationpersonalization could also be transmitted as part of the deliverycontext, but are outside the scope of this document since they are inherentlyapplication-dependent.
Because the kind of content that is delivered may depend on thecharacteristics that are conveyed in the delivery context, it is importantthat the user is provided, through appropriate software and interaction, withsufficient flexibility to control those characteristics. This is particularlyimportant where the needs of the user may differ from those provided instandard configurations.
Currently it is not clear how privacy of delivery context information isbest addressed. The user may not wish certain pieces of information containedin the delivery context to be made available to untrusted components alongthe delivery path. For example, the user may wish information about theirlocation to be made available to a trusted application, but not to anyintermediate node through which the delivery context information may pass.This and other characteristics in the delivery context, individually orcollectively, may indirectly constitute personally identifiable information,and so are subject to the security and privacy concerns considered in moredetail in Section6.3.
From the perspective of the application developer or content author, it isimportant to be able to access delivery context information in order todeliver the most appropriate kind of content.
In some situations, the application developer may rely on some underlyingadaptation process to select and format the appropriate content version. Forexample, commercial image servers are available that can scale and convertthe format of images to suit the rendering capabilities of differentdevices.
In other situations, the content author may indicate within their contentthat different selections should be made according to the clientcapabilities. For example, markup to express context-dependent styling hasbeen included in CSS Media Queries[MQ]. Proposals to allow context-dependent contentselection are under development[DI-sel].
In yet other situations, the application developer may explicitly createtransformations which can adapt their content for different devices. Forexample, stylesheets written in XSLT may be applied to content expressed inXML to produce different deliverable presentation markup.
In order to make effective use of the delivery context information, theapplication developer needs the characteristics to be both well-defined andcommon across as many devices as possible. This raises issues of thedefinition and re-use of vocabulary elements, as discussed in Section5.4.
Delivery context support may need to be implemented in system componentssuch as user agents, web servers and proxy servers. From the point of view ofa delivery context system implementer, several components need to be definedto ensure interoperable implementations:
Specific implementations might further define ways in which deliverycontext information might be accessed via application program interfaces orcached in data repositories.
Delivery context information may capture diverse aspects of an accessmechanism, may be augmented or processed by different kinds ofintermediaries, and may be used by different application components in anorigin server or intermediary. This means delivery context has to besupported by many software components along the delivery path. It will notnecessarily be the case that a single software component creates the wholedelivery context, and another single component accepts it and adapts contentaccordingly.
From the perspective of the implementer, software components must be ableto create a delivery context, augment an existing delivery context with theirown characteristics, replace parts of a delivery context to reflect thepossible adaptation capabilities of the component, and decompose a deliverycontext to extract the characteristics which will control theirprocessing.
To date, the user agent, usually based on the client, has been thesoftware component that has been responsible for constructing a request forsome Web content, and has therefore also assumed responsibility for creatingany client-related delivery context. However, with access mechanisms that mayincreasingly include several hardware or software components, a more flexibleway of building the delivery context will be required.
For example, a mobile device may be temporarily within range of a localLAN which provides fast Internet access as well as connection to a nearbyprinter and a large screen. By interacting with their mobile device, the usermay wish to deliver some Web content on the printer or the screen. Thedelivery context may include characteristics, or references tocharacteristics, contributed by several components. Hardware characteristicsmay be provided by the printer, the screen and the mobile device. Softwarecharacteristics may be provided by the mobile device's operating system, useragent, and local media handling capabilities. Network characteristics may beprovided relating to the LAN connection. User preferences may be providedrelating to the user experience of the content to be accessed.
As the range of characteristics made available through the deliverycontext grows, so the implementer of the content adaptation process requiresbetter mechanisms to extract the relevant characteristics from the deliverycontext.
For example, if multiple overlapping characteristics exist within thedelivery context, such as the pixel dimensions of the presentation spaces ofeach of the mobile device, the printer and the screen in the previousexample, resolution rules or other mechanisms are required to determine whichcharacteristics should be used.
The overall Architecture of the World Wide Web[WEB-arch] describes how information resources canbe accessed and how multiple representations of the resource may beretrieved. This section looks at the role of delivery context within thisoverall architecture.
The role of the delivery context in accessing web-based content andapplications is illustrated in the following diagrams.
Diagram 3.1: Client provides delivery context as well as request
The client which originates a request for some web content may alsoinclude some delivery context information which can help that request to behandled appropriately. In practice, the context information may be includedas part of the request, or some (or all) of it may be supplied indirectly asa reference to information that is stored separately.
Delivery context information may also be used locally. For example, theamount of ambient light may be part of the delivery context information thatis used to alter the brightness of a display. However, this use of deliverycontext is independent of the Web architecture.
Diagram 3.2: Server uses delivery context to adapt response
The server which responds to some request for web content may use deliverycontext information to adapt its response to better suit the needs of theclient. Such server-side adaptation may include providing an appropriate data(MIME) type for the response, or an appropriate natural language in which toexpress text content, or even selecting appropriate application-specific datasuited to the locale of the client.
Diagram 3.3: Intermediary may augment delivery context and adapt response
An intermediary in the path between client and server may also provideadaptation. The intermediary may modify the request, including providing newdelivery context information, in such a way that the response can be adaptedappropriately. For example, a transcoding proxy may offer to accept a mediatype not included in the original request. When the response is received bythe proxy, that media type is adapted to one that is acceptable to theoriginator of the request.
In the most general situation, a sequence of intermediaries may provideadditional delivery context information at different points in the requestpath from client to server and may modify the response in the response pathbetween the server and the client. The response may be modified based on anydelivery context information available at that point in the response path.
In some situations, an intermediary may block delivery context informationfrom being passed further along the request path. For example, a phone maypass information about its location only as far as a mobile gateway, whichdoes not make it available to the origin server.
The delivery context also has wider significance than its usage indeveloping adapted content. The application that runs on the user agent(typically the client device) can utilize the device and environment contextinformation for providing contextual adaptation. One mechanism for accessingthe system and environment context is the Delivery Context Interfaces (DCI)developed by the DI working group. Here, through the use of applicationscripts, a decision can be made as to whether adaptation can continue on theclient side or new content is needed from server based on the currentcontext.
Various approaches to defining delivery context, or at least some aspectsof it, already exist. Indeed, the need to negotiate which version of adocument should be delivered to a user was recognized in the early days ofthe Web[HTTPneg].
In this section, the main approaches that are already in use on the Webare reviewed.
The Hypertext Transport Protocol HTTP[HTTP] is the basis for most current Web-basedinformation delivery. It defines a number of standard accept headers that canbe used to match the capabilities of a requesting device (or, in particular,its user agent) to the information that is delivered from an origin server.Standard HTTP 1.1 accept headers include:
In addition to the accept headers, the User-Agent header usually containsa string giving information about the user agent. Typically this includes thename of the manufacturer, the version number and a name. For mobile devices,it often includes information about the device hardware and the browser beingused. There are no standards about how user agent information is constructed.Nevertheless, sophisticated algorithms may use it to try to identify thedevice and browser software being used. A number of existing systems use thisidentification to access a repository of information about the capabilitiesof the device and browser. Adaptation of content for user experience can thenbe made based on knowledge of these capabilities.
While HTTP headers are currently the most widely used delivery contextinformation, they are difficult to extend, and have (particularly in the caseof the User-Agent header) free-form values that are difficult tointerpret.
It is possible for a server to select content based simply on the HTTPheader information. In HTTP 1.1[HTTP] this is calledserver-drivennegotiation.
In this case, the server determines which alternate to send to a useragent as a result of examining the user agent's request header fields.Currently HTTP 1.1 uses the following request-header fields, as described inthe previous subsection, for server-driven negotiation: Accept,Accept-Charset, Accept-Encoding, Accept-Language. Each of these fields isreferred to as a dimension of negotiation. In order to express user orbrowser preferences, the request-header fields may include an associatedquality value for each dimension of negotiation.
For example the following header indicates that French resources arepreferred to English resources.
Accept-Language: fr; q=1.0, en; q=0.5
There are some disadvantages associated with server-driven negotiation.Firstly the information sent in the request header does not give a completedescription of the capabilities of the client. For example there is no way todistinguish between images intended for handheld computers from desktopcomputers if they both use the same MIME type. Secondly it is inefficient fora user agent to describe its full capabilities to a server for every requestit makes. Finally server-driven negotiation causes problems for caches sharedby multiple devices.
It is also possible within HTTP 1.1 to supportagent-drivennegotiation, in which the user agent is responsible for selecting themost appropriate content. The server initially responds with a list ofavailable representations, which then allows the user agent to make anotherrequest for the preferred representation. However, this has the disadvantageof introducing additional delay through multiple request-response roundtrips.
The W3C has specified a data structure and sample vocabulary for profileswhich can convey delivery context information. The current CompositeCapabilities/Preferences Profile (CC/PP)[CCPP-struct-vocab] is based on theoriginal XML serialized Resource Description Framework (RDF)
The CC/PP structure is vocabulary independent and allows the use of one ormore vocabularies which may be optionally described using RDF Schema.(See also the RDF Primer[RDF-primer] section 6.7 on "Describing DeviceCapabilities and User Preferences".)
As CC/PP is vocabulary neutral, it allows different vocabularies to bedeveloped and implemented by communities involved in developing applications,devices and browsers. It also allows for the dynamic composition of adelivery context profile from fragments of capability information that may bedistributed among multiple repositories on the web.
CC/PP is the preferred approach to communicating delivery contextinformation between clients, intermediaries and origin servers. It is thebasis forUAProf, which is currently used to expressthe capabilities of many mobile devices. There are a number ofimplementations available[CCPP-implem] which consume CC/PPprofiles, and there is also a Java Community Process interface definition forprofile consumers[JSR188].
The current CC/PP Recommendation[CCPP-struct-vocab] provides a structureand a sample vocabulary based on the version of RDF current during itsdevelopment. It is expected to be brought up to date with the latestrevisions of RDF[RDF-concepts] and RDF Schema
TheOpen Mobile Alliance(OMA, formerly the WAP Forum) has defined a User Agent Profile
WAP 1.2.1 recommends transporting UAProf information over the Internetusing the HTTP Extension Framework[HTTPex] which was originally suggested for CC/PP[CCPP-exchange]. WAPdefined the WSP protocol, which includes a compressed encoding, for usebetween the phone and the gateway onto the Internet. Due to the lack ofimplementations of HTTPex, WAP 2.0 instead defined an extension of HTTP 1.1as an Internet protocol (W-HTTP) that uses custom headers.
The WAP Forum also defined a UAProf vocabulary, based on CC/PP, thatincludes hardware and software characteristics as well as WAP specificfeatures of the mobile terminal and associated transport network. Subsequentupdating, to UAProf V2.0, by OMA has based the definition on the latestversion of RDF and RDF Schema.
WURFL , [WURFL], is a free, open source project thatprovides an alternative source of information to UAProf. It tries to providea comprehensive resource of device information, and contains deviceinformation for 4500 variants of devices. Because WURFL is open source,anyone can correct device information, not just device manufacturers. WURFLprovides its own XML format for device characteristics description.
In W3C recommendations, such as CSS and HTML, style markup can be madeconditional on delivery context by using Media Queries[MQ]. These introduce another vocabulary for accessingdevice characteristics.
Media Queries build upon the use of 'media types' as defined in CSS2
In the future, it should therefore be possible to add device-dependentstyling to common device-independent content, at least as far as the CSSmedia types and media features will allow.
Like CSS, Media Queries are typically expected to be processed directly inuser agents, based on local delivery context information. However, they couldalso be fully or partially processed at servers or intermediaries in theresponse path, based on delivery context information passed as part of arequest for content. This highlights the need for the vocabulary used for thedevice capabilities passed in the delivery context to correspond to thevocabulary used within Media Queries.
A further W3C standard, the Synchronized Multimedia Integration Language(SMIL) introduces yet another vocabulary for accessing a limited number ofdevice characteristics.
SMIL 2.0[SMIL] is defined asa set of markup modules that can be integrated into specific languageprofiles. In particular, it defines a BasicContentControl Module that definescertain system characteristics that may be used to control a SMILpresentation. These characteristics may be given dynamic values according tothe runtime environment. Like Media Queries, they therefore allow a useragent that supports dynamic SMIL characteristics to access local deliverycontext information.
System test characteristics included as part of the SMILBasicContentControl Module cover presentation-related capabilities such asscreen size, network bandwidth, and text and audio captions, as well assystem-related characteristics such as CPU and operating system identity.
The following approaches have been proposed, but have not been widelyimplemented to date.
Transparent Content Negotiation[TCN], was first proposed as an experimental protocolinRFC 2295.
Transparent negotiation uses both HTTP server-driven and agent-drivennegotiation mechanisms (as described in Section4.2), together with a caching proxy that supportscontent negotiation. The proxy requests a list of all availablerepresentations from the origin server using agent-driven negotiation, thenselects the most appropriate and sends it to the client using server-drivennegotiation. However, this technique has not been widely implemented.
The IETF Content Negotiation working group[Conneg] focused on defining the features whichcould form the basis for negotiation. In particular, inRFC 2506, a procedure wasdefined for registering Media Feature Tags in a central Internet AssignedNumbers Authority (IANA)registry.
A further result of the Conneg work was a proposal for combining MediaFeatures Tags into Media Feature Sets[MFS]. InRFC 2533, a syntax forexpressing Boolean combinations of features is proposed and an algorithm forfeature set matching (see also[FSM]) is also described.
ISO/IEC is defining the MPEG-21[MPEG-21] framework which is intended to supporttransparent use of multimedia resources across a wide range of networks anddevices. The fundamental unit of distribution is the 'digital item', which isan abstraction for some multimedia content with associated data.
One aspect of the requirements for MPEG-21 is Digital Item Adaptationwhich is based on a Usage Environment Description (see section 4.7.2 in
While existing techniques provide some basic support for delivery contextinformation, there are a number of areas that remain to be addressed. The W3CDevice Independence Working Group (DIWG) is chartered[DI-charter] to carry out further work ondelivery context and its use in web authoring.
The W3C Delivery Context Workshop held in March 2002[DCW] gave an opportunity for presentation anddiscussion about technologies associated with device independent delivery,and delivery context in particular. The workshop identified a number of areasrelating to delivery context where further work was necessary.
For example, among some of the topics discussed were:
For further details see theposition papers,presentations andworkshop notes.
This remainder of this section summarizes the areas of ongoing work withinDIWG and the issues that are currently being addressing.
The current W3C recommendation for representing delivery contextinformation is CC/PP, as described in Section4.3.
Some aspects of the original proposals of the CC/PP working group wereomitted in the current recommendation due to lack of implementationexperience. These include support in the profile for describing thecapabilities of transcoding proxies, which may in some cases extend theeffective capabilities of a device. For example, they may allow a wider rangeof image formats to be accepted in an HTTP response from a server, since theproxy can transcode them into an image format accepted by a particulardevice.
It has already been mentioned that a revised version of CC/PP is underconsideration that would make fuller use of the latest version of RDF. Inparticular, RDF now supports the explicit association of data values withtheir data type. This has the potential to allow CC/PP profiles to be moreself-describing, in that type information about capabilities would no longerneed to be defined in an RDF schema that was separately conveyed to theprofile consumer.
In order to implement the interoperable exchange of delivery contextinformation, it is necessary to specify how the information is conveyed aspart of a request protocol. Apart from the use of HTTP headers to expresssome limited aspects of delivery context as described earlier, no consensushas been reached on how more general delivery context information can beconveyed.
A proposal was made for a protocol for CC/PP based on the HTTP ExtensionFramework[CCPP-exchange], but in practice thisframework has not been widely implemented.
UAProf[UAProf] has defineda protocol based on additionalad hoc HTTP header fields.
However, there is still a need to standardize an extensible way ofconveying delivery context, beyond the existing header fields, as part of anHTTP 1.1 request.
Protocol design is non-trivial. Care must be taken, especially if it is toaffect many web requests, not to introduce inefficiencies. For example, tominimize additional use of network bandwidth, a protocol should encourageoptimizations such as indirect reference to static parts of the contextinformation or caching of unchanging characteristics. A protocol should alsoallow intermediaries, if necessary, to access and augment the contextualinformation with minimal overhead.
Session-based management of context could be considered, complementing thewidely implemented HTTP state management using cookies, as described inRFC 2965. If delivery contextinformation were associated with a session, it might not be necessary toconvey the full context with each request. Instead, it might be possible tosimply notify changes from the previous context data.
Further work on CC/PP Protocol is included in the charter of the DeviceIndependence Working Group[DI-charter]. This will focus on a protocol foruse with conventional stateless HTTP requests. Work on session-basedprotocols is out of the current scope.
It is not sufficient simply to define how delivery context information canbe conveyed as part of a communication protocol. For the end-to-end semanticsof the delivery process to be well defined and predictable, it is alsonecessary to consider how the context information is resolved and madeavailable to the adaptation or negotiation mechanisms at the different pointsin the delivery chain described in Section3.
Profile information could be distributed across multiple locations on theweb. It may not be consolidated and made available all in one place. Forexample, a hardware manufacturer and a software provider may make the staticcapabilities of their respective parts of an access mechanism available ontheir own websites, whereas network capabilities may depend on the routing ofa particular request. So it should be possible to retrieve distributedcapability information and compose or derive the delivery context at anyappropriate point in the delivery path. To do this flexibly, a deliverycontext should be able to use combinations of characteristics from multiplevocabularies, or multiple versions of a single vocabulary, that relate todifferent aspects of an access mechanism. For example CC/PP uses XMLnamespaces to distinguish characteristics from different vocabularies.
Since a delivery context may be built from characteristics provided bydifferent components along the delivery path, it should be possible toaccumulate delivery context information provided by different components. Themeans of accumulation could simply consist of appending the information fromdifferent sources in separate profiles, or of combining them into a singleprofile. It should not be assumed that any particular component along thepath is capable of resolving the information further.
Resolution rules can be used to describe how characteristics may defaultor override. However, if different rules are created for differentcharacteristics, the complexity of the resolution process can quickly grow.Resolution mechanisms may be specific to each application, or applicationindependent resolution mechanisms may be used for all applications thatdepend on the same profile. For example the UAProf standard specifiesapplication independent resolution rules.
Processing rules are also necessary to define the behavior of processingsequences such as a client, an intermediary acting as a proxy and an originserver. Here the client device and the proxy may provide different versionsof the same characteristics, so it is necessary to disambiguate. Similarly,there may be a need to deal with aggregated devices, such as connecting aphone and PDA in order to provide voice and text browsing. Here one of thedevices may merge the profiles from the phone and the PDA in order to allowthe server to provide a multimodal interface. In this case it is necessary todetermine which of the client devices, and possibly which modality or othergrouping on that device, provides a particular characteristic.
Delivery context characteristics must also fit into authoring andadaptation environments, and allow individual characteristics to be accessedas part of page adaptation on origin servers as well as by intermediaries andclients.
In DIWG, it is intended to cover CC/PP processing at the same time as workon CC/PP protocol, since the two are closely related in theirimplementation.
Delivery context information is expressed in terms of values ofcharacteristics which may be drawn from, and are defined in, one or morevocabularies.
In the overview of existing and proposed approaches, it is clear that manygroups have started to define vocabularies that could be used to expressaspects of delivery context. For device capabilities alone, there are alreadyMedia Features defined in the IANA registry as part of the Conneg work,different versions of the UAProf vocabulary defined by the Open MobileAlliance, Media Queries as part of CSS style, system characteristics in SMIL,and an example CC/PP vocabulary.
Vocabularies for delivery context characteristics need to be standardizedso that authoring and adaptation processes can use them in a consistentfashion to select or generate suitable user experiences.
It is inevitable that vocabularies for characteristics will evolve througha number of different versions. It is also likely that they will need toincorporate characteristics that have been defined in other approaches forother purposes, as illustrated in the range of potential characteristicsdescribed in Section1.1. There is a dangerthat vocabularies and their versions may proliferate so that the task ofinterpreting them and making appropriate adaptations to delivered contentbecomes unmanageable.
It should be possible to declare a set of characteristics as a vocabularythat can be combined with other vocabularies for other characteristics. Bysharing sets of characteristics between vocabularies, it should be possibleto minimize the number of different characteristics that might be introducedfor essentially similar capabilities. CC/PP, by being based on RDF, naturallysupports such definition and re-use.
It is preferable to re-use characteristics whenever possible duringvocabulary definition. However, it may also be possible to separatelyidentify equivalences between characteristics from different vocabularies ata later date. The Web Ontology Language[OWL] provides a means both for defining the propertiesand classes that might make up a vocabulary as well as making explicit therelationships, such as disjointness and equivalence, there might be betweenthem.
Some of the markup languages referred to in Section4 already provide mechanisms for authors torefer to delivery context characteristics when creating web pages. Inparticular, CSS Media Queries and SMIL introduce ways of referring to alimited set of characteristics. CSS is intended to be used for adding stylinginformation to other markup languages, such as XHTML and SVG, and so allowsdelivery context dependent styling to be expressed in a uniform way for thelanguages which incorporate it, at least for the few characteristics itdefines. The set of characteristics introduced by SMIL is also small, anddefined in a way specific to that language.
In anticipation of the need to express content selection for web pagesthat is dependent on delivery context, a draft proposal has been produced byDIWG for a context-dependent way of expressing Content Selection
The Delivery Context Interfaces (DCI) work being developed by DIWG definesa platform independent API for accessing delivery context information. Theinterface allows mechanisms to both query and update properties. For dynamicproperties, 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 differentorganizations. The Open Mobile Alliance (OMA) has developed a set ofproperties for describing static characteristics of mobile phones. Devicevendors are expected to define additional properties for proprietaryfeatures.
A set of XHTML Document Profile Requirements were proposed in 1999
This leads to considering the broader use of metadata, created as part ofdocument authoring, as a means of guiding the adaptation of content for aparticular delivery context. At the time of writing, W3C is about to hold aWorkshop on Metadata forContent Adaptation to explore this topic further.
While it is not the purpose of this document to identify specificrequirements, it is useful to collect together some remaining open issues,beyond the work described in the previous section.
It may be useful to identify the source of delivery context informationprovided by different components along the delivery path, and to extract theinformation from the delivery context provided by each source.
By identifying the source of some delivery context information, it may bepossible to do a better job of adapting the content. For example, a requestfor printed output made via a phone may include device capabilities for theprinter (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 isimportant that these can be distinguished and separately extracted.
In addition, it may be important for assessing the reliability of thedelivery context information, or the trust to be placed in it, for its sourceto be identified.
If document metadata (as mentioned in Section5.6), or some similar mechanism, is used to describe thecapabilities required of the delivery device, there needs to be a way ofmatching this to the delivery context information so that appropriate contentcan be delivered.
With the modularization of markup languages such as XHTML, SVG, CSS andSMIL, a mechanism is also required for representing and negotiating whichmodules are supported by a user agent and which modules are required tosuccessfully deliver a document. For example, the 3GPP specification forPacket Switched Streaming service[3GPP-PSS], which is based on SMIL, defines itsown vocabulary for capability exchange based on UAProf and includes a meansof enumerating supported SMIL modules.
Several techniques have been proposed to perform capability negotiationbetween devices: for example SyncML for data synchronization or the WirelessVillage Initiative for instant messaging - both of these are now consolidatedinto theOpen MobileAlliance.
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 thatinformation is handled. Ultimately this could extend to providing securitymeasures for ensuring the privacy of sensitive information.
An early working draft of CC/PP Implementors Guide on Privacy andProtocols[CCPP-trust]includes a discussion on privacy issues within the CC/PP framework, includingexamples of how the recommendations of the Platform for Privacy PreferencesProject[P3P] could be used withCC/PP. It also includes an Appendix on "Basicrequirements for trust management frameworks".
Issues that relate to trust include:
Many of these issues are beyond the scope of device independence. Iflimited information about device and network capabilities can be freelyshared, the user can benefit from receiving content better suited to thedelivery device. This is the case currently, for example, in the use of HTTPheader information. However, if such capability information is withheld, theuser should still be provided with a functional user experience.
However, it is necessary to consider the potential misuse of anycharacteristics that are provided in good faith in order to achieve a betteruser experience, and to balance this against the benefits. Ultimately, theuser should be given control over whether user experience-relatedcharacteristics are made available by a user agent as part of the deliverycontext. In addition, it may be necessary to include in the delivery contextitself, or in the definition of its processing, rules that indicate what mayor may not be changed or acted on by intermediaries.
This document has focused on delivery context in a traditional Webdelivery environment. In other words, the focus has been on the conveying ofdelivery context information from a client to a server, via possibleintermediaries, using HTTP.
However, the general principles may be applicable to other environmentsusing other protocols. For example,Multimodal Interaction andWeb Services use alternatives to, orextensions of, HTTP. However, they both have the need to describe thecharacteristics of the context into which they are delivering the results ofweb requests.
In particular, even if the details of conveying delivery contextinformation in a particular protocol may differ, the representation of thatinformation, and the vocabularies on which it depends, may be shared acrossmany environments. The benefits of re-using the syntax and semantics ofdevice and other delivery context characteristics in different environmentsare greater interoperability and reduced implementation costs.
Delivery context information may be useful across a wide range ofdistributed application domains, and not least for achieving deviceindependence for the Web. In this domain, it provides the key information onwhich better adaptation of content across different access mechanisms mustdepend.
This document has provided an overview of progress in representing andusing delivery context for this purpose. The W3C Device Independence WorkingGroup is chartered to continue work on further topics in this area.
Members of the W3C Device Independence Working Group have helped developthis Working Group Note through their comments, proposals and discussions atteleconferences, face-to-face meetings and via the group discussion list.
At the time of publication, the principal and active members of the groupwere as follows:
The following were members of the group at earlier stages of itsdrafting:
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.