Guidelines for Web Content Transformation Proxies - Implementation Conformance Statement

This version:
This document is an appendix to:
Latest version of "Guidelines for Web Content Transformation Proxies":
François Daoust, W3C
See Acknowledgments in Guidelines for Web Content Transformation Proxies.


This document is an appendix to Guidelines for Web Content Transformation Proxies [CT-SPEC]. It provides a tabular checklist of all normative clauses containing the key words should or should not from the guidelines, sorted by topic. Please refer to Guidelines for Web Content Transformation Proxies [CT-SPEC] for the full statement and context description of the excerpts listed below, as well as references to related documents.

Status of This Document

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 http://www.w3.org/TR/.

This document is derived from and is an appendix to Guidelines for Web Content Transformation Proxies [CT-SPEC], which is a draft document, produced by the Content Transformation Task Force of the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. Please see the "Status of this document" section of the corresponding guidelines specification [CT-SPEC] for complete details about the status of the guidelines version from which this is extracted and which it accompanies.

Please send comments on this document to the Working Group's public email list public-bpwg-ct@w3.org, a publicly archived mailing list.


This checklist includes excerpts of all defined normative clauses containing the key words should and should not from the Guidelines for Web Content Transformation Proxies [CT-SPEC] presented in a tabular format. The statements are presented by order of their topic.

The Conformance section of the Guidelines for Web Content Transformation Proxies specification requires Transformation Deployments that wish to claim conformance to the specification to make available a conformance statement that specifies the reasons for non-conformance with any clauses containing the key words should or should not. This presentation is intended to be the base template of such a conformance statement.

The table includes spaces for scoring each statement, "yes" (compliance), "no" (non-compliance), "n/a" (not applicable), and comments. The comments section must specify the reasons for non-compliance with a given clause.

Clauses table

Guidelines YES NO N/A Comments
4.1.1 Applicable HTTP Methods
Proxies should not intervene in methods other than GET, POST, HEAD.
If the HTTP method is altered from HEAD to GET, proxies should (providing such action is in accordance with normal HTTP caching rules) cache the response so that a second GET request for the same content is not required (see also 4.1.4 Serving Cached Responses ).
4.1.4 Serving Cached Responses
Aside from the usual caching procedures defined in [RFC 2616 HTTP], in some circumstances, proxies may paginate responses and where this is the case a request may be for a subsequent page of a previously requested resource. In this case proxies may for the sake of consistency of representation serve stale data but when doing so should notify the user that this is the case and should provide a simple means of retrieving a fresh copy.
4.1.5 Alteration of HTTP Header Values
Proxies should not change headers other than User Agent and Accept(-*) headers and must not delete headers. It must be possible for the server to reconstruct the original UA originated headers (see Original Headers ).
Other than to comply with transparent HTTP operation, proxies should not modify any request headers unless:
In this section, the concept of "Web site" is used (rather than "origin server") as some origin servers host many different Web sites. Since the concept of "Web site" is not strictly defined, proxies should use heuristics including comparisons of domain name to assess whether resources form part of the same "Web site". Content Tasting
The theoretical idempotency of GET requests is not always respected by servers. In order, as far as possible, to avoid mis-operation of such content, proxies should avoid issuing duplicate requests and specifically should not issue duplicate requests for comparison purposes. User Selection of Restructured Experience
Proxies should assume that by default users will wish to receive a representation prepared by the Web site. Proxies must assess whether a user's expressed preference for a restructured representation is still valid if a Web site changes its choice of representations (see 4.2.6 Receipt of Vary HTTP Header ). Sequence of Requests
When requesting resources that are included resources (e.g. style sheets, images), proxies should make the request for such resources with the same User-Agent header as the request for the resource from which they are referenced.
4.1.6 Additional HTTP Headers
proxies should add the IP address of the initiator of the request to the end of a comma separated list in an X-Forwarded-For HTTP header; Proxy Treatment of Via Header
Proxies must (in accordance with compliance to RFC 2616) include a Via HTTP header indicating their presence and should indicate their ability to transform content by including a comment in the Via HTTP header consisting of the URI "http://www.w3.org/ns/ct".
4.2.1 Applicable Responses
Proxies should not intervene in response if the request method was not HEAD, GET or POST.
4.2.6 Receipt of Vary HTTP Header
A proxy may not be carrying out content tasting as described under Avoiding "Request Unacceptable" Responses if it anticipates receiving a "request unacceptable" response. However, if it makes a request with altered headers in these circumstances, and receives a response containing a Vary header referring to one of the altered headers then it should request the resource again with unaltered headers. It should also update whatever heuristics it uses so that unaltered headers are presented first in subsequent requests for this resource.
4.2.7 Link to "handheld" Representation
If the response is an HTML response and it contains a <link rel="alternate" media="handheld" /> element, the CT-proxy should request and process the referenced resource, unless the resource referenced is the current resource as determined by the presence of link elements as discussed under D.1.3.2 Indication of Intended Presentation Media Type of Representation .oops a reference to something that isn't normative any more
4.2.8 Proxy Decision to Transform
In the absence of a Vary or no-transform directive (or a meta HTTP-Equiv element containing Cache-Control: no-transform) proxies should apply heuristics to the response to determine whether it is appropriate to restructure or recode it (in the presence of such directives, heuristics should not be used.) Alteration of Response
A proxy should strive for the best possible user experience that the user agent supports. It should only alter the format, layout, dimensions etc. to match the specific capabilities of the user agent. For example, when resizing images, they should only be reduced so that they are suitable for the specific user agent, and this should not be done on a generic basis.
The altered content should validate according to an appropriate published formal grammar;
It should indicate to the user that the content has been transformed for mobile presentation and provide an option to view the original, unmodified content.
5 Testing (Normative)
Operators of transforming proxies should make available interfaces that facilitate testing of Web sites accessed through them and should make such interfaces available through normal Internet access paths.


Guidelines for Web Content Transformation Proxies , Jo Rabin, mTLD Top Level Domain (dotMobi), Working Draft, http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107.