Content Transformation Guidelines 1e

Group Working Draft 26 February 2008

This version:
Latest version:
Previous version:
Jo Rabin, dotMobi


This document is the Guidelines referred to in the Charter of the W3C Mobile Web Initiative Best Practices Working Group Content Transformation Task Force.

Its purpose is to provide guidance to implementors of components of the delivery context as to how to communicate their intentions and capabilities in respect of content transformation.

Status of this Document

This document is an editors' copy that has no official standing.

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 W3C technical reports index at

Publication as a Group Working Draft 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.

This document has been produced by the Content Transformation Task Force of the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative . Please send comments on this document to the Working Group's public email list, a publicly archived mailing list .

This document was produced under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of patent disclosures made in connection with this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification must disclose the information in accordance with section 6 of the W3C Patent Policy.

Revision Description

Fourth Editor's Draft

See [todo] for a list of to do s.

Table of Contents

1 Introduction
    1.1 Purpose
    1.2 Scope
    1.3 Audience
2 Guidelines
    2.1 Summary of Requirements
    2.2 Objectives
    2.3 Types of Proxy
    2.4 Proxy States
    2.5 Types of Transformation
    2.6 Control of the Behavior of the Proxy
    2.7 Control by Server
    2.8 Control by Administrative or Other Arrangements.
3 Behavior of Components
    3.1 Client Origination of Request
    3.2 Proxy Receipt, Forwarding or response to a Request
        3.2.1 Alternative 1
        3.2.2 Alternative 2
        3.2.3 Proxy Interaction with the User when Active
    3.3 Server Response to Proxy
    3.4 Proxy Receipt and Forwarding of Response from Server
    3.5 Proxy Response to Client
4 Use Case Analysis
5 Testing
6 Conformance


A Scope for Future Work (Non-Normative)
B References (Non-Normative)
C Acknowledgments (Non-Normative)
D To Do (Non-Normative)

1 Introduction

2 Guidelines

2.1 Summary of Requirements

Rev 1e: Note that this is now beyond the scope we agreed, but there is still stuff here we want to say.

The purpose of this section is to summarize the communication requirements of actors (transforming proxies, origin servers, and to some extent users) to communicate with each other. The relevant scenario involving a content transformation proxy is as follows:

The needs of these actors are as follows:

  1. The user agent needs to be able to tell the content transformation proxy [@@and the origin server]:

    1. what type of mobile device and what user agent is being used;

    2. what media-type (presentation format e.g. desktop, handheld) the user desires;

    3. that all content transformation should be avoided, or that reformatting is allowed/desired.

  2. The content transformation proxy needs to be able to tell the origin server:

    1. that some degree of content transformation (re-coding and reformatting) can be performed;

    2. that content transformation will be carried out unless instructed not to;

    3. that content is being requested on behalf of something else [@@?? and what that something else is];

    4. that the request headers have been altered (e.g. additional content types inserted).

  3. The origin server needs to be able to tell the content transformation proxy:

    1. that it varies its presentation according to device type and other factors;

    2. that it's permissible or otherwise to perform content transformation of various kinds;

    3. that it has media-specific representations;

    4. that is unable or unwilling to deal with the request in its present form.

  4. The content transformation proxy needs to be able to tell the client browser:

    1. that it has applied transformations of various kinds to the content;

    2. how to access the untransformed representation of the content.

  5. The content transformation proxy needs to be able to interact with the user:

    1. to allow the user to disable its features;

    2. to alert the user to the fact that it has transformed content and to allow access to an untransformed representation of the content.

2.3 Types of Proxy

Alteration of HTTP requests and responses is not prohibited by HTTP other than in the circumstances referred to in [HTTP] section 13.5.2. This document describes how the Client and the Destination Server may require conforming transforming proxies not to alter HTTP requests and responses.

HTTP defines two types of proxy: transparent proxies and non-transparent proxies. As discussed in Section 1.3 [HTTP], Terminology:

"A [Definition: transparent proxy] is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A [Definition: non transparent proxy] is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies."

This document elaborates the behavior of non-transparent proxies, when used for content transformation in the context discussed in [Content Transformation Landscape] and henceforward referred to as transforming proxies.

2.4 Proxy States

Rev 1e: I don't know if this is needed any more

A transforming proxy is viewed as being in one of two states in respect to a client and a server. In the [Definition: active] state it may transform content and manipulate HTTP headers. In the [Definition: passive] state it behaves like a transparent proxy and behaves as though a Cache-Control: no-transform directive were present on every request and every response, with the possible exception that - only with the consent of both the user and the content provider - content which it has been determined would cause serious mis-operation of the client, such as causing it to crash, may be minimally transformed to prevent that mis-operation.


In practice, the passive state may be achieved by the proxy being by-passed.

3 Behavior of Components

3.2 Proxy Receipt, Forwarding or response to a Request

Rev 1e: Most removed from this section

Irrespective of the presence of the no-transform directive, the proxy must behave transparently (q.v.) if it detects that the user agent is not a browser [@@open question as to how it does that].

If the request contains a no-transform directive for a resource that has already been served to the client, it may respond with a cached untransformed copy of the resource, providing that serving that response is in accordance with the cache-control directives that the server attached to the untransformed response.

If the request contains a Cache-Control: no-transform directive the proxy must forward the request unaltered to the server, other than to comply with transparent HTTP behavior and in particular to add a Via HTTP header.

Rev 1e: The USD1M question is, do we specify what the following looks like?

The proxy must (in accordance with compliance to RFC 2616) include a Via HTTP header indicating its presence.

If there is no no-transform directive present in the request the proxy should analyze whether it intends to offer transformation services by referring to any administrative arrangements that are in place with the user of the client, or the server, and any a priori knowledge it has of client capabilities [@@ from a DDR and so on]. Knowing that the client has available a linearization or zoom capability and/or supports a broad range of content formats the proxy should not recode content.

If as a result of this deliberation it intends to (restructure / reformat / compress) the proxy must indicate this by including a [@@@ I will transform (restructure / reformat / compress)] - [@@ and even if it doesn't it may indicate its potential for restructuring or recoding or compressing content [@@by means of ...].

Proxies must not intervene in HTTPS requests and should not intervene in methods other than [@@we have an open question here as to which methods are applicable].

A proxy should not alter HTTP requests unless not doing so would result in the users request being rejected by the origin server (this includes HTTP 406 status as well as HTTP 200 status, saying that the request cannot be handled - e.g. "Your browser is not supported").

Rev 1e: The following section needs more discussion before I can edit it

3.3 Server Response to Proxy

The following para is probably unnecessary

Servers should distinguish URIs that are intended for access only by HTTPS from those that are intended for insecure access in order to be able to detect and reject requests that should have been submitted by HTTPS but have been re-written in contravention of its directives.

If the server varies its presentation according to examination of received HTTP Headers then it must include a Vary HTTP header indicating this to be the case. If, in addition to, or instead of HTTP headers, the server varies its presentation on other factors (source IP Address ...) then it must include a * as one of the fields in the Vary response.

The server must include a no-transform directive if one is received from the client. If it is capable of varying its presentation it should take account of client capabilities [@@as derived from a DDR etc.] and formulate an appropriate experience according to those criteria.

If the server has distinct presentations according to its perception of the presentation media, then the medium for which the presentation is intended should be indicated [@@using the ...] This is going to be something like the link headers, I think

If the server creates a specific user experience for certain presentation media types it should inhibit transformation of the response by including a no-transform directive.

Note that including a no-transform directive may [@@should actually] disrupt the behavior of WAP/WML proxies, because this inhibits such proxies from converting WML to WMLC (because this is a content-encoding behavior).

Servers may base their actions on a priori knowledge of behavior of transforming proxies, when they are identified in a Via header.

The server should not choose a Content-Type for its response based on its assumptions about the heuristic behavior of any intermediaries. (e.g. it should not choose content-type: application/vnd.wap.xhtml+xml solely on the basis that it suspects that transforming proxies will apply heuristics that make them not restructure it).

[@@ Vary headers in 406 response - restrict to the one(s) that have caused the 406.??]

Servers should respond with a 406 not a 200 if they can't handle the request. Servers should provide information about alternative representations by using the Vary header (if the alternatives are available from the same URI) or using link information if alternative representations are handled by different URIs. [This restricts to HTML for now. If link headers a reinstated in HTTP then this becomes a more universal mechanism. Open question as to whether it SVG or WICD etc. support any such notion]

[@@300 Response - could this be used as a signal from the server to say that it understands the protocol? A la RFC 2295]

3.5 Proxy Response to Client

If the response includes a Warning: 214 Transformation Applied the proxy must not apply further transformation.

If the response includes a Cache-Control: no-transform directive then the response must be forwarded to the client unaltered other than in the respects noted for transparent operation of HTTP proxies as specified in RFC2616, and in particular the addition of a Via HTTP header.

In the absence of a Vary or no-transform directive the proxy should apply heuristics to the content to determine whether it is appropriate to restructure or recode it (in the presence of such directives, heuristics should not be used.)

  • The server has previously shown that it is contextually aware, even if the present response does not indicate this - modified by a need for the proxy to be aware that the server has changed its behavior and is no longer aware in that way

  • the content-type is known to be specific to the device or class of device e.g. application/vnd.wap.xhtml+xml

  • examination of the content reveals that it is of a specific type appropriate to the device or class of device e.g. DOCTYPE XHTML-MP or WBMP or [@@mobile video] [@@ note Sean's extensive list of heuristics that should be included as an informative example?]

  • The response is an HTML response and it includes <link> elements specifying alternatives according to media type [or that such links are included as HTTP headers] or that the content has a mobileOK label.

If the proxy alters the content then it must add a Warning: 214 Transformation Applied HTTP Header. [@@ should this be elaborated to say what kind of transformation?]

If the response contains URIs with the scheme https the proxy must not rewrite them unless [@@er actually this should be a discussion of intercepting links that were https and either a) informing the user of them being now insecure, or alternatively that content transformation is not going to be applied so they may get garbage].

If the proxy has transformed (reformatted) the content but not rewritten https links it should annotate those links to indicate that transformation service is not available on them.

A proxy should strive for the best possible user experience that the client supports. It should only alter the format, layout, dimensions etc. to match the specific capabilities of the client. For example, when resizing images, they should only be reduced so that they are suitable for the specific client, and this should not be done on a generic basis.

Rev 1e: Did we say we would remain silent on this?

In the passive mode (as well as in the active mode), if the proxy determines that the resource as currently represented is likely to cause serious mis-operation of the client then the proxy may transform the resource but only sufficiently to alter the specific aspect of the content that is likely to cause mis-operation. Proxies must not exhibit this behavior unless this has been specifically allowed by both the server and the user. [@@ either by persistent registration of preferences, or by use of the [@@correct dangerous content] directive.]

4 Use Case Analysis

Client Proxy Server

Unaware, Unaware, Unaware etc.


5 Testing

All ... must be tested for deleterious effects ... [@@TBD]

Providers of transforming proxies should make available interfaces that facilitate testing of Web sites accessed through them. [@@ though how they should make known how to do this and what administrative arrangements would be needed are both probably out of scope]

6 Conformance

A Scope for Future Work (Non-Normative)

A placeholder for the bits we couldn't do

B References (Non-Normative)

Mobile Web Best Practices 1.0 Basic Guidelines, Jo Rabin, Charles McCathieNevile (eds), W3C Proposed Recommendation, 2 November 2006 (See
Content Transformation Landscape 1.0, Jo Rabin, Andrew Swainston (eds), W3C Working Draft 25 October 2007 (See
Hypertext Transfer Protocol -- HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999 (See

C Acknowledgments (Non-Normative)

The editors acknowledge contributions of various kinds from members of the MWI BPWG Content Transformation Task Force.

The editor acknowledges significant written contributions from:

D To Do (Non-Normative)

Work needed on this draft:

There could be a note that the host should provide interactions that allow the user to have a choice of presentations and so should the proxy and the client, for that matter.

Another as yet unopened Pandora's box is that the discussion and proposed text looks at the issues primarily from the point of view of "varying presentation from Thematically consistent URIs". What hasn't, as yet, been explored is how it all works if there is a common entry point to a site (Thematically consistent URI for a home page) which then dispatches via redirect to media specific versions. This is possibly rather more common than the previous case (e.g. redirect to - or rather better, imo, Naturally, there will also be varying presentation even within a redirected solution. This whole area needs further thought.

We need a discussion as to what extent we should be drawing up an RFC to do what we want to do. On the one hand HTTP makes it clear, in explaining how to introduce extensions that it expects such extensions to be introduced. On the other hand, we do typically take a conservative approach and say if it is not in the IANA registry then it's not an existing protocol and therefore beyond our scope. Introducing extensions to existing header values, to my mind falls short of introducing new headers. Though it's not clear that we can do what we need to if we don't do that, go through IANA registration and so on.

We need to discuss what relationship, if any, this has to the following RFCs:

RFC 2295 is experimental, but actually gets to some of the points we want to make, though doesn't exactly address what we are doing. It's rather a lengthy and detailed read, and has a lot of features that we don't need. It does, however, introduce a couple of headers and field values which have been IANA registered. Also, the main points of the negotiation are implemented in Apache in mod_negotiation (see [APACHE]).


IANA registration is probably a bit of a nuisance, and may be something we don't need to do - e.g. it would seem that the q parameter for content type and much else is not registered. For those of you who fancy a bit of train spotting, I think you'll find registered things at [IANA], though I confess I find this all a bit impenetrable and difficult to navigate.