2. Overview

2.1 Background

Providers of "made for mobile" Web sites have increasingly found that their intentions are not realised when their content in presented in certain delivery contexts (q.v.). This is as a result of components of those delivery contexts (q.v.) not realising that the intention of the providers of those sites is expressly to create a "made for mobile" experience for their users.

2.2 Purpose of this Document

This document is an Addendum to the dotMobi Switch On! Web Developer Guide [SOWDG] which recommends creating one or more user experiences that are sympathetic to the user's context. It provides interim and partial guidance to providers who have followed that recommendation as to how to indicate their intentions in the presence of components of the delivery context that might alter those user experiences.

Specifically, it describes how origin servers addressable using the .mobi top level domain may indicate to components of the delivery context whether or not they vary their content in response to aspects of the HTTP [HTTP] request headers and whether or not they wish to allow their content to be transformed by components of the delivery context.

2.3 Related Standards, Recommendations and Best Practices

The document is produced in recognition of the work of the W3C Mobile Web Initiative Best Practices Working Group Content Transformation Task Force and is intended to be complementary to that work, to stimulate debate and encourage participation in that work.

2.4 Terminology

Capitalised words, such as MUST, MAY, SHOULD, are to be interpreted in the sense defined in [RFC2119].

The following terms are used with the specific meanings indicated:

Delivery Context

The environment, including components of the delivery context and the preferences of the user, into which content is delivered (See definition from [DIGLOSS]).

Components of the Delivery Context

Specific identifiable entities within the delivery context that may play an active role in the formatting or presentation of the content, including proxies, gateways, browsers and devices.

Functional User Experience

A representation that allows a user to experience the intentions of the provider (See definition from [DIGLOSS]).

Origin Server

An entity to which an HTTP request is directed and which generates a response to that request (See definition from [DIGLOSS]).

3. Recommendations

3.1 Scope

The .mobi top level domain is intended to provide an indication that providers have deliberately created a "made for mobile" experience on their Web sites. Sites addressable using the .mobi domain are required to take certain minimum steps to provide a functional user experience and are recommended to take more substantial steps to achieve this. It can be inferred from the domain name alone that providers have a commitment to providing at least a "functional user experience" to mobile users.

The purpose of this recommendation is to help providers explicitly reinforce the message conveyed implicitly by the domain name alone. It recommends the use of two existing HTTP header constructs to inform components of the delivery context of the intentions of the provider in respect of their content.

The two HTTP constructs concerned are the Cache-Control: no-transform directive and the Vary: header.

3.2 Actions of .mobi Domain Origin Servers

3.2.1 Use of the Vary HTTP Header

Origin servers that vary the representation of their resources according to details of the HTTP request they receive SHOULD add a Vary HTTP header to their response, informing downstream components that different representations are available.

Origin servers often adjust the representation of their content according to the value of the User-Agent header received in the HTTP request. It is recommended that such servers add Vary: User-Agent to their responses. Doing so informs components of the delivery context that if they have adjusted the User-Agent header in the request then the response the Vary header is attached to may be inappropriate, and that it was not necessarily the intention of the provider that this representation is appropriate to the user's actual delivery context.

Origin servers MAY choose to add other information to the Vary header indicating that the response varies according to other HTTP headers.

Example: Vary: User-Agent, Accept, Accept-Language

See 14.44 Vary for more information about the Vary HTTP header.

3.2.2 Use of the Cache-Control: no-transform Directive

By adding the no-transform directive to their Cache-Control HTTP header, origin servers MAY indicate to components of the delivery context that the content of their response is to be delivered exactly as they have represented it.

Example: Cache-Control: max-age=30, no-transform

See 14.9.5 No-Transform Directive for more information

3.3 Interpretation of .mobi Domain Origin Servers

Components of the delivery context, whether or not they are in any way associated with the .mobi domain, SHOULD take the following actions on receipt of the Vary HTTP Header and Cache-Control: no-transform directive when received from a .mobi domain origin server.

1. In the absence of either indication

   Sites that have a .mobi domain name indicate, by this alone, that they have regard to the user's context. Components of the delivery context SHOULD exercise EXTREME CAUTION before considering altering aspects of a response and SHOULD NOT alter the contents of requests and responses without having due regard for the provider's intentions.

2. In the presence of the Vary header

   The site has indicated that it varies the representation according to details of the request. Components of the delivery context MUST provide accurate details of the user's actual context, as represented by the HTTP headers in the request, in order to be confident that the provider's intentions are realised correctly.

3. In the presence of the no-transform directive

   Components of the delivery context MUST NOT alter the representation of the content.

4. In the absence of a no-transform directive but the presence of a Vary header

   Components of the delivery context, MAY, with the user's consent, alter the representation. The default behaviour is that a transforming component SHOULD NOT alter representations.