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/.
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-compliance with any clauses containing the key words should or should not. This presentation is intended to provide a base template for such a conformance statement.
The table includes spaces for scoring each statement: "Compliance" to assert compliance and "Reason for non-compliance" to specify the reasons for non-compliance with a given clause. Non-compliance to absolute requirements of the specification, i.e. normative statements that use the terms must, must not, shall or shall not, is forbidden. The "Reason for non-compliance" column of absolute requirements is marked as "N/A" (Not Applicable).
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 ).
Other than to convert between HEAD and GET proxies must not alter request methods.
[...] 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 must provide a simple means of retrieving a fresh copy.
Aside from the usual procedures defined in [RFC 2616 HTTP] proxies should not modify the values of header fields other than
the User-Agent, Accept, Accept-Charset, Accept-Encoding, and Accept-Language header fields [...]
[...] and must not delete header fields.
N/A
[...] It must be possible for the server
to reconstruct the original User Agent originated header
fields by copying directly from the corresponding
X-Device header field values (see 4.1.5.5 Original Header Fields ).
N/A
Other than to comply with transparent HTTP operation, proxies should not modify any request header fields unless one of the following applies: [...]
[...] 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".
A proxy must not reissue a POST request with altered header fields when the response to the unaltered POST request has HTTP status code 200 (in other words, it may only send the altered request for a POST/PUT request when the unaltered one resulted in an HTTP 406 response, and not a "request unacceptable" response).
Proxies must assume that by default users will wish to receive a representation prepared by the Web site.
N/A
[...] If a user has made such a choice then proxies may alter header field values when requesting resources in
order to reflect that choice, but must, on receipt of
an indication from a Web site that it offers alternative representations
(see H.1.4.2 Indication of Intended Presentation Media Type of Representation ), inform the user of that and allow them to select an alternative representation.
N/A
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 Field ).
[...] g. style sheets, images), proxies should
make the request for such resources with the same User-Agent header field as the request for the resource from which they are referenced.
When requesting linked resources that do not form part of the same Web
site as the resource from which they are linked, proxies should
not base their choice of header fields on a consistency of presentation premise.
When forwarding an HTTP request with altered HTTP header fields, in addition to complying with the rules of normal HTTP operation, proxies
must include in the request copies of the
unaltered header field values in the form "X-Device-"<original
header name> .
N/A
[...] For example, if the User-Agent
header field has been altered, an X-Device-User-Agent header field
must be added with the value of the received
User-Agent header field.
N/A
Specifically the following mapping must be used: [...]
Proxies must (in accordance with RFC
2616) include a Via HTTP header field indicating their presence [...]
N/A
[...] and should indicate their ability to transform content by including a comment in the Via HTTP header field consisting of the URI "http://www.w3.org/ns/ct".
When forwarding Via header fields, proxies should
not alter them by removing comments from them.
In the following, proxies must check for the presence of equivalent <meta http-equiv> elements in HTML content, if the relevant HTTP header field is not present.
Proxies must provide a means for users to express preferences for inhibiting content transformation even when this has been chosen by the user as the default behavior.
N/A
[...] Those preferences must be maintained on a user by user and Web site by Web site basis.
N/A
Proxies must solicit re-expression of preferences in respect of a server if the server starts to indicate that it offers varying responses as discussed under 4.2.6 Receipt of Vary HTTP Header Field .
If the response includes a Cache-Control: no-transform directive
then proxies must not alter it other than to comply with
transparent HTTP behavior as described in [RFC 2616 HTTP]Section 13.5.2 and Section 14.9.5 and other than as follows.
[...] However, if it makes a request with altered header fields in these circumstances, and receives a response containing a Vary header field referring to one of the altered
header fields then it should request the resource again with unaltered header fields.
[...] It should also update whatever heuristics it uses so that unaltered header fields are presented first in subsequent requests for this resource.
If the response is an HTML response and it contains a <link
rel="alternate" media="handheld" /> element, a proxy
should request and process the referenced resource,
unless the resource referenced is the current representation .
In the absence of a Vary or no-transform directive
(or a meta HTTP-Equiv element containing Cache-Control:
no-transform) proxies should not transform content matching any of the following rules unless the user has specifically requested transformation: [...]
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.
Operators of content transformation proxies should make available an interface through which the functions of the proxy can be exercised.
[...] The operations possible through this interface must cover those necessary to settle the outcome of all conformance statements listed in section B.
N/A
The interface must be reachable from terminals with browsing capabilities connected to the Web via a conventional Internet access environment at the tester's premises; [...]
N/A
Such access must be granted under fair, reasonable and non-discriminatory conditions.