Diagram 1: Requestor provides context as well as request
Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document provides an overview of the role of delivery context in assisting device independent presentation for the Web. It surveys current techniques for conveying delivery context information, and identifies further developments that would enhance the ability to adapt content for different access mechanisms.
This document has no official standing. It is an informal draft made available for comment and early feedback. It may contain sections that are incomplete or inconsistent.
This document is published as part of the W3C Device Independence Activity by the Device Independence Working Group. It is a deliverable as defined in the Charter of that group.
Comments on this document may be sent to the public [email protected] mailing list (archived at http://lists.w3.org/Archives/Public/www-di/).
A list of current W3C Recommendations and other technical reports can be found at http://www.w3.org/TR.
The Device Independence Principles document [DIP] set out a number of principles that can lead to greater device independence in delivering Web content and applications.
The term delivery context was introduced (in [DIP]) to refer to the set of attributes that characterize the delivery environment. Among these attributes, the ones that are most relevant for achieving device independence are those that characterize the presentation capabilities of the access mechanism, the delivery capabilities of the network and the presentation preferences of the user.
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 presentation device. The selection or adaptation required to achieve this may be performed by an origin server, by an intermediary in the delivery path, or by a user agent.
From the point of view of device independence, the main concern is accurately reflecting the capabilities of the access mechanism and the presentation preferences of the user. Given appropriate information about the delivery context, the presentation of the delivered content can be selected or adapted to be functional on that device, or may be further customized to provide a better user experience (as defined in [DIP]). The possible adaptations that could be performed on the available content can only be determined once the delivery context information is known.
In this document, techniques for representing, conveying and processing delivery context are considered. Existing technologies that address these needs are reviewed. Areas that need further work are highlighted.
The role of the delivery context in accessing web-based content and applications is illustrated in the following diagrams.
Diagram 1: Requestor provides context as well as request
The originator of a request for some web content may also define some delivery context information which can help that request to be handled appropriately. In the diagram, the context information is show as a separate box. However in practice it may be supplied directly as part of the request, or indirectly as a reference to some information that is already stored separately, or some of the information may be supplied directly and the rest supplied indirectly.
Diagram 2: Adaptor may change response based on context
The response to some request for web content may be adapted, based on the delivery context information available at that point in the delivery chain, to create a modified response.
Diagram 3: Requestor and adaptor may act together as an intermediary
A requestor and adaptor may act together as an element in the delivery path providing a specific part of the adaptation. The requestor may modify the request, including providing new context information, in such a way that the response can be adapted appropriately. For example, a transcoding proxy may offer to accept a media type not included in the original request. When the response is received by the proxy, that media type is adapted to one that is acceptable to the originator of the request.
Diagram 4: Client originates the request and server originates the response
In the most general situation, a sequence of requestors may provide additional delivery context information at different points in the request path from client to server. Similarly, a sequence of adaptors may modify the response in the response path between the server and the client. The response may be modified based on any delivery context information available at that point in the response path.
In some situations, delivery context information may only be available to a restricted set of adaptors. A requestor may block context information from being passed further up the request path, or may only make it available to an associated adaptor. For example, a phone may pass information about its location only as far as a mobile gateway, which does not make it available to the origin server.
In this section, motivation for more effective use of delivery context information is provided from the perspectives of users, authors and implementers.
From the perspective of the user, the technology for conveying delivery context is largely invisible. For example, a user is not usually aware of the attribute values inserted into an HTTP request header. But the user may need a mechanism to set preferred attribute values when necessary.
Some aspects of the delivery context, such as the underlying capabilities of the access mechanism, can be set automatically by software through internal configuration parameters. An example of such an attribute might be the screen size of a visual rendering device.
Other aspects of the delivery context, such as user preferences, will usually require user configuration. Some preferences may relate to presentation choices, often managed by the user agent responsible for rendering some Web content. For example, a user may set their preferred language for delivered text within their browser options. Other preferences may relate to application choices, managed by specific application software running on the client. Applications sometimes use cookies, stored by the browser, to hold such preferences.
Since the kind of content that may be delivered may depend on the attributes that are conveyed in the delivery context, it is important that the user is provided, through appropriate software and interaction, with sufficient flexibility to control those attributes. This is particularly important where the needs of the user may differ from those provided in standard configurations.
Currently it is not clear how privacy of delivery context information is best addressed. The user may not wish certain pieces of information contained in the delivery context to be made available to untrusted components along the delivery path. For example, the user may wish information about their location to be made available to a trusted application, but not to any intermediate node through which the delivery context information may pass. This and other attributes 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 later.
From the perspective of the application developer or content author, it is important to be able to access delivery context information in order to deliver the most appropriate kind of content.
In some situations, the application developer may rely on some underlying adaptation process to select and format the appropriate content version. For example, commercial image servers are available that can scale and convert the format of images to suit the rendering capabilities of different devices.
In other situations, the content author may indicate within their content that different selections should be made according to the client capabilities. For example, markup to express this was proposed as part of XHTML under the name of Document Profiles [XHTMLprof], and has been included in CSS under the name of Media Queries [MQ].
In yet other situations, the application developer may explicitly create transformations which can adapt their content for different devices. For example, stylesheets written in XSLT may be applied to content expressed in XML to produce different deliverable presentation markup.
In order to make effective use of the delivery context information, the application developer needs the attributes conveyed by the information 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 later.
From the point of view of a delivery context implementor, several components need to be defined to ensure interoperable implementations:
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. This means delivery context has to be supported by many software components along the delivery path. It will not, in general, be the case that a single software component creates the whole delivery context, and another single component accepts it and adapts content accordingly.
From the perspective of the implementor, software components must be able to augment an existing delivery context with their own attributes, must be able to replace parts of a delivery context to reflect the possible adaptation capabilities of the component, and must be able to decompose a delivery context to extract the attributes which will control their processing.
To date, the user agent, usually based on the client, has been the software component that has been responsible for constructing a request for some Web content, and has therefore also assumed responsibility for creating any client-related delivery context. However, with access mechanisms that may increasingly include several hardware or software components, a more flexible way of building the delivery context will be required.
For example, a mobile device may be temporarily within range of a local LAN which provides fast Internet access as well as connection to a nearby printer and a large screen. By interacting with their mobile device, the user may wish to deliver some Web content on the printer or the screen. The delivery context may include attributes, or references to attributes, contributed by several components. Hardware attributes may be provided by the printer, the screen and the mobile device. Software attributes may be provided by the mobile device's operating system, user agent, and local media handling capabilities. Network attributes may be provided relating to the LAN connection. User preferences may be provided relating to the content to be accessed.
As the range of attributes made available through the delivery context grows, so the implementor of the content selection and adaptation process requires better mechanisms to extract the relevant attributes from the delivery context.
For example, if multiple overlapping attributes exist within the delivery context, such as the pixel dimensions of the presentation spaces of each of the mobile device, the printer and the screen in the previous example, resolution rules or other mechanisms are required to determine which attributes should be used.
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 recognised in the early days of the Web [HTTPneg].
In this section, the main approaches that are already in use on the Web are reviewed.
The Hypertext Transport Protocol HTTP [HTTP] is the basis for most current Web-based information delivery. It defines a number of standard accept headers that can be used to match the capabilities of a requesting device (or, in particular, its user agent) to the information that is delivered from an origin server. Standard HTTP 1.1 accept headers include:
In addition to the accept headers, the User-Agent header usually contains a string giving information about the user agent. Typically this includes the name of the manufacturer, the version number and a name. For mobile devices, it often includes information about the device hardware and the browser being used. There are no standards about how user agent information is constructed. Nevertheless, sufficiently sophisticated algorithms use it to try to identify the device and browser software being used. A number of existing systems use this identification to access a repository of information about the capabilities of the device and browser. Adaptation of content for presentation can then be made based on knowledge of these capabilities.
It is possible for a server to select content based simply on the HTTP header information. In HTTP 1.1 [HTTP] this is called server-driven negotiation.
In this case, the server determines which alternate to send to a user agent as a result of examining the user agent's request header fields. Currently HTTP 1.1 uses the following request-header fields for server-driven negotiation:
Each of these fields is referred to as a dimension of negotiation. In order to express user or browser preferences, the request-header fields may include an associated quality value for each dimension of negotiation.
For example the following header indicates that French resources are preferred to English resources.
Accept-Language: fr; q=1.0, en; q=0.5
There are some disadvantages associated with server-driven negotiation. Firstly the information sent in the request header does not give a complete description of the capabilities of the client. For example there is no way to distinguish between images intended for handheld computers from desktop computers if they both use the same MIME type. Secondly it is inefficient for a user agent to describe its full capabilities to a server for every request it makes. Finally server-driven negotiation causes problems for caches shared by multiple devices.
It is also possible within HTTP 1.1 to support agent-driven negotiation, in which the user agent is responsible for selecting the most appropriate content. The server initially responds with a list of available representations, which then allows the user agent to make another request for the preferred representation. However, this has the disadvantage of introducing additional delay through multiple request-response round trips.
The W3C CC/PP Working Group has specified a structure for profiles, called CC/PP (Composite Capabilities/ Preferences Profile), which is based on the XML serialized Resource Description Framework (RDF). This profile structure is vocabulary independent and allows the use of one or more vocabularies which may be optionally described using RDF Schema. As CC/PP is vocabulary neutral, it allows different vocabularies to be developed and implemented by application developer, device manufacturer and browser developer communities.
CC/PP allows for the dynamic composition of a delivery context profile from fragments of capabilities information that may be scattered/ distributed among multiple repositories on the web. Support for capabilities asserted by intermediate proxies and gateways is also enabled.
The draft CC/PP recommendation [CCPP-struct-vocab] suggests a possible vocabulary, but does not define a protocol for exchanging profiles, and does not specify how the profile should be used within any mechanism for content adaptation.
There are two associated CC/PP Implementors Guides. The Guide on Privacy and Protocols [CCPP-trust] discusses protocol issues as well as the way in which the privacy of profiles could be protected, including the use of mechanisms such as those defined by P3P [P3P]. The Guide on Harmonizing with Existing Vocabularies and Content Transformation Heuristics [CCPP-coordination] discusses how different vocabularies could fit within the CC/PP framework and suggests some approaches to content adaptation.
The WAP Forum has defined a User Agent Profile [UAProf] as an implementation of CC/PP for WAP-enabled mobile terminals, providing convergence of mobile web technologies with that of the classic web.
WAP 1.2.1 recommends transporting UAProf information over the Internet using the HTTP Extension Framework [HTTPex] which was originally suggested for CC/PP [CCPP-exchange]. WAP defined the WSP protocol, which includes a compressed encoding, for use between the phone and the gateway onto the Internet. Due to the lack of implementations of HTTPex, WAP 2.0 instead defines an extension of HTTP 1.1 as an Internet protocol (W-HTTP) that uses custom headers.
The WAP Forum has also defined a profile vocabulary that include assertions regarding the hardware and software characteristics and WAP specific features of the mobile terminal and associated transport network capabilities.
Vendors of WAP proxies and browsers are beginning to offer commercial implementations of UAProf and the 3GPP Mobile Execution Environment (MExE) group has adopted the UAProf - CC/PP framework for MExE terminals.
Within W3C standards such as CSS and HTML, style markup can be made conditional on delivery context by using Media Queries [MQ]. These introduce yet another vocabulary for accessing device attributes.
Media Queries build upon the use of 'media types' as defined in CSS2 [CSS2], which allow styles to be conditional on a number of named categories of device: aural, braille, embossed, handheld, print, projection, screen, tty and tv. In Media Queries, device attributes ('media features') may be queried and combined using a restricted expression syntax. The style used to present an element of HTML, XHTML or XML can therefore be made conditional on the attributes of the delivery device. By making use of the CSS 'display' property, it is also possible to conditionally include or exclude complete elements from the presentation.
In the future, it should therefore be possible to add device-dependent styling to common device-independent content, at least as far as the CSS media types and media features will allow.
Like CSS, Media Queries are typically expected to be processed directly in user agents, based on local delivery context information. However, they could also be fully or partially processed at servers or intermediaries in the response path, based on delivery context information passed as part of a request for content. This highlights the need for the vocabulary used for the device capabilities passed in the delivery context to correspond to the vocabulary used within Media Queries.
The following approaches have been proposed, but have not been widely implemented to date.
Transparent Content Negotiation [TCN], was first proposed as an experimental protocol in RFC 2295.
Transparent negotiation uses both HTTP server-driven and agent-driven negotiation mechanisms (as described above), together with a cacheing proxy that supports content negotiation. The proxy requests a list of all available representations from the origin server using agent-driven negotiation, then selects the most appropriate and send it to the client using server-driven negotiation. However, this technique has not been widely implemented.
The IETF Content Negotiation working group [Conneg] focused on defining the features which could form the basis for negotiation. In particular, in RFC 2506, a procedure was defined for registering Media Feature Tags in a central Internet Assigned Numbers Authority (IANA) registry.
A further result of the Conneg work was a proposal for combining Media Features Tags into Media Feature Sets [MFS]. In RFC 2533, a syntax for expressing Boolean combinations of features is proposed and an algorithm for feature set matching (see also [FSM]) is also described.
A set of XHTML Document Profile Requirements were proposed in 1999 [XHTML-docprofile]. These could be seen as complementary to device attributes, in that they could define attributes that would be required of the device in order to successfully deliver a document.
A proposed new architecture for Open Pluggable Edge Services (OPES) is being developed within IETF [OPES]. This provides the means for a server to delegate the content adaptation to an intermediary in such a way that it does not break the end-to-end model of the internet. Furthermore, the intermediary may make use of remote services to carry out the adaptation. The OPES archtecture requires extensions to the HTTP protocol that allow the server to authorize and specify such transformations. OPES does not set out new proposals for representing delivery context, but is concerned with ways in which the context may relate to, or be used to control, adaptation services.
ISO/IEC is defining the MPEG-21 [MPEG-21] framework which is intended to support transparent use of multimedia resources across a wide range of networks and devices. The fundamental unit of distribution is the 'digital item', which is an abstraction for some multimedia content with associated data.
One aspect of MPEG-21 is Digital Item Adaptation [MPEG-21-DIA] which is based on descriptions of the environment (including delivery context) and adaptability of the content. It includes the definition of vocabularies for content preferences, presentation preferences, terminal capabilities and network characteristics.
While existing techniques provide basic support for delivery context information, there are a number of issues that remain to be addressed. This section summarizes some that have been raised to date.
Two specific principles relating to delivery context were proposed in the Device Independence Principles [DIP].
DIP-6: The user agent should be able to associate the characteristics of the delivery context with a request of a particular Web page identifier.
DIP-7: It should be possible for a user to provide or update any presentation preferences as part of the delivery context.
In addition, in Section 3.2, an area of further work was identified.
For device independence to become widely supported, it will be necessary to indicate how the transition can be made from existing widely supported techniques of representing the delivery context towards future, more complete, proposals such as CC/PP.
At a more implementation-specific level, this document has shown the delivery context being associated with a request for a Web page. There are several possibilities here. It is not necessary that the whole context is sent with each request. It could be that only a reference to the context is sent. Or that the context is managed on a session basis, or based on profiles stored elsewhere.
CC/PP provides a possible representation for conveying delivery context information. However, the way in which the delivery context should be generated by the access mechanism (user agent) and the interpretation of the delivery context by the server (and possibly also by intermediate proxies) will need further recommendations to be developed. Ways of conveying the delivery context in device independent ways using existing techniques, prior to CC/PP becoming widely adopted, should also be considered.
The W3C Delivery Context Workshop held in March 2002 [DCW] gave an opportunity for presentation and discussion about technologies associated with device independent delivery, and delivery context in particular. The workshop identified a number of areas relating to delivery context where further work was necessary.
For example, among some of the topics discussed were:
For further details see the position papers, presentations and workshop notes.
While it is not the purpose of this document to identify specific requirements, it is useful to collect together open issues.
Capability information could be distributed in 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 attributes 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 attributes from different vocabularies.
Since a delivery context may be built from attributes 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.
It should be possible to identify the source of delivery context information provided by different components along the delivery path, and to extract the information from the delivery context provided by each source. By identifying the source of some delivery context information, it may be possible to do a better job of adapting the content. For example, a request for printed output made via a phone may include device capabilities for the printer (so that the output can be formatted for it) as well as for the phone (so that any print control or error messages can be displayed on it). It is important that these can be distinguished and separately extracted. In addition, it may be important for assessing the reliability of the delivery context information, or the trust to be placed in it, for its source to be identified.
Delivery context information is expressed in terms of values of attributes which may be drawn from, and are defined in, one or more vocabularies.
In the overview of existing and proposed approaches, it is clear that many groups have started to define vocabularies that could be used to express aspects of delivery context. For device capabilities alone, there are already Media Features defined in the IANA registry as part of the Conneg work, different versions of the UAProf vocabulary defined by the WAP Forum, Media Queries as part of CSS style, and an example CC/PP vocabulary.
Vocabularies for device capabilities need to be standardized so that authoring and adaptation processes can use them to select or generate suitable presentations.
It is inevitable that vocabularies for device capabilities will evolve through a number of different versions. It is also likely that they will need to incorporate attributes that have been defined in other approaches for other purposes.
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.
For a discussion on the use of different vocabularies within the CC/PP framework, see the CC/PP Implementors Guide [CCPP-coordination].
It seems clear there is a need for a well-defined, machine-readable, way of declaring a vocabulary for use in a delivery context.
It should be possible to declare a set of attributes as a vocabulary module that can be included in multiple other vocabularies. By sharing sets of attributes between vocabularies, it should be possible to minimise the number of different attributes that might be introduced for similar capabilities. It is prefereable to re-use attributes whenever possible during vocabulary definition rather than have to separately identify equivalences between attributes from different vocabularies at a later date.
Further work on Core Device Attributes is included in the charter of the Device Independence Working Group [DI-charter].
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.
For a discussion on the use of different protocols within the CC/PP framework, see the CC/PP Implementors Guide on Privacy and Protocols [CCPP-trust].
A proposal was made for a protocol for CC/PP based on the HTTP Extension Framework [CCPP-exchange], but in practice this framework has not been widely implemented.
UAProf [UAProf] has defined a protocol based on additional ad hoc HTTP header fields.
However, there is still a need to standardize an extensible way of conveying delivery context, beyond the existing header fields, as part of an HTTP 1.1 request.
Protocol design is non-trivial. Care must be taken, especially if it is to affect many web requests, not to introduce inefficiencies. For example, to minimize additional use of network bandwidth, a protocol should encourage optimisations such as indirect reference to static parts of the context information or caching of unchanging attributes. A protocol should also allow intermediaries, if necessary, to access and augment the contextual information with minimal overhead.
Session-based management of context could be considered, complementing the widely implemented HTTP state management using cookies, as described in RFC 2965. If delivery context information were associated with a session, it might not be necessary to convey the full context with each request. Instead, it might be possible to simply notify changes from the previous context data.
Further work on CC/PP Protocol is included in the charter of the Device Independence Working Group [DI-charter]. This will focus on a protocol for use with conventional stateless HTTP requests. Work on session-based protocols is out of the current scope.
It is not sufficient simply to define how delivery context information can be conveyed as part of a communication protocol. For the end-to-end semantics of the delivery process to be well defined and predictable, it is also necessary to consider how the context information is resolved and made available to the adaptation or negotiation mechanisms.
Resolution rules can be used to describe how attributes may default or override. However, if different rules are created for different attributes, the complexity of the resolution process can quickly grow.
Delivery context attributes must also fit into authoring and adaptation environments, and allow individual attributes to be accessed from server pages and applications on origin servers as well as by intermediary adaptors.
A current Java Community Process proposal [JSR188] will define a set of Java APIs for accessing CC/PP attributes as well as provide a reference server-side implementation.
If document profiles, or some similar mechanism, are used to describe the capabilities required of the delivery device, there needs to be a way of matching these to the delivery context information so that appropriate content can be delivered.
With the modularization of markup languages such as XHTML, SVG, CSS and SMIL, a mechanism is also required for representing and negotiating which modules are supported by a user agent and which modules are required to successfully deliver a document. For example, the 3GPP specification for Packet Switched Streaming service [3GPP-PSS], which is based on SMIL, defines its own vocabulary for capability exchange based on UAProf and includes a means of enumerating supported SMIL modules.
Currently several standards perform capability negotation between devices: for example SyncML for data synchronisation or the Wireless Village Initiative for push messaging. These standards describe device capabilities using profiles consisting of two types of elements: descriptive elements and structural elements. Descriptive elements describe the properties of the device, such as the width of the device screen in pixels. Structural elements on the other hand may perform two roles: they either group related elements together, or they allow disambiguation which makes it possible to distinguish between multiple descriptive elements that refer to the same property in a profile or a set of profiles.
When a device involved in capability negotiation receives a profile, it typically interprets the descriptive elements in one of three ways. If a descriptive element has a single value, it is regarded as a constraint that must be met by the other device. If it contains multiple values, then it is either regarded as a choice available to the other device, or it is necessary to perform resolution. This is done by examining the structural context of the multiple values within the profile to see whether to select one value to use as a constraint, or to select a subset of values to regard as a choice.
In capability negotiation, either the 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 mechanisms. CC/PP does not propose a complete set of resolution mechanisms, so makes the assumption that application dependent resolution mechanisms will be used.
It is also possible to make a distinction between serial or parallel disambiguation. Serial disambiguation may be required when a number of elements are connected in a serial chain. For example, the chain might contain a client, and intermediary acting as a proxy and an origin server. Here the client device and the proxy may provide different versions of the same properties, 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 is necessary to perform parallel disambiguation to determine which of the client devices, and possibly which modality or other grouping on that device, provides a particular property.
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.
For a discussion on privacy issues within the CC/PP framework, see the CC/PP Implementors Guide on Privacy and Protocols [CCPP-trust]. This includes examples of how P3P could be used with CC/PP. It also includes an Appendix on "Basic requirements for trust management frameworks".
Issues that relate to trust include:
Many of these issues are beyond the scope of device independence. If limited information about device and network capabilities can be freely shared, the user can benefit from receiving content better suited to the delivery device. This is the case currently, for example, in the use of HTTP header information. However, if such capability information is withheld, the user should still be provided with a functional presentation.
However, it is necessary to consider the potential misuse of any attributes that are provided in good faith in order to achieve a better presentation, and to balance this against the benefits. Ultimately, the user should be given control over whether presentation-related attributes 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.
The following definitions are taken from the HTTP/1.1 specification (RFC 2616) [HTTP] and from Device Independence Principles [DIP].
This document was produced by members of the Device Independence Working Group, whose membership at the time of publication is shown below. It does not yet represent a consensus view.