W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > October to December 2009

Re: Feedback on content transformation guidelines ( LC-2066 LC-2067 LC-2068 LC-2069 LC-2070 LC-2071 LC-2073 LC-2072 LC-2074 LC-2075 LC-2076 LC-2077 LC-2078 LC-2079 LC-2080 LC-2081 LC-2082 LC-2083 LC-2084)

From: <fd@w3.org>
Date: Tue, 06 Oct 2009 15:34:18 +0000
To: Mark Nottingham <mnot@mnot.net>
Cc: public-bpwg-comments@w3.org
Message-Id: <E1MvC3O-00033A-HR@wiggum.w3.org>

 Dear Mark Nottingham ,

The Mobile Web Best Practices Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the Content Transformation
Guidelines 1.0 published on 1 Aug 2008. Thank you for having taken the time
to review the document and to send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:

Please review it carefully and let us know by email at
public-bpwg-comments@w3.org if you agree with it or not before 6 November
2009. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation


For the Mobile Web Best Practices Working Group,
Dominique Hazaël-Massieux
François Daoust
W3C Staff Contacts

 1. http://www.w3.org/mid/427CE896-3572-4F32-8C9D-589B59AEE7D5@mnot.net
 2. http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/


Your comment on 2.1 Types of Proxy:
> * Section 2.1 - "Alteration of HTTP requests and responses is not  
> prohibited by HTTP other than in the circumstances referred to in  
> [RFC2616 HTTP] Section 13.5.2."  This isn't true; section 14.9.5 needs 
> to be referenced here as well.

Working Group Resolution (LC-2066):
We agree that section 14.9.5 refers to this and have changed the reference

The updated text is available at:


Your comment on 3.4 Content Deployment Conformance:
> * Section 3.4 / 3.5 "A [Content|Transformation] Deployment conforms to 
> these guidelines if it follows the statements..."  What does "follows" 
> mean here -- if they conform to all MUST level requirements? SHOULD  
> and MUST?

Working Group Resolution (LC-2067):
We agree that this is unclear. The guidelines now state that conformance
applies to SHOULD statements as well and that a justification is required
for each circumstance in which a SHOULD statement is not followed.
Transformation Deployments willing to claim conformance to the spec must
make available a conformance statement available as a separate document and
referenced from the guidelines.

Check the updated version of the text:


Your comment on 4.1.2 no-transform directive in Request:
> * Section 4.1.2 "If the request contains a Cache-Control: no-transform 
> directive proxies must forward the request unaltered to the server,  
> other than to comply with transparent HTTP behaviour and as noted  
> below."  I'm not sure what this sentence means.

Working Group Resolution (LC-2068):
We agree and have added references to the revelant sections of RFC2616, as
well as to the section of the guidelines that points out the HTTP header
fields proxies should add.

The updated text is available at:


Your comment on 4.1.3 Treatment of Requesters that are not Web browsers:
> * Section 4.1.3 "Proxies must act as though a no-transform directive  
> is present (see 4.1.2 no-transform directive in Request) unless they  
> are able positively to determine that the user agent is a Web  
> browser."  How do they positively" determine this? Using heuristics is 
> far from a guaranteed mechanism. Moreover, what is the reasoning  
> behind this? If the intent is to only allow transformation of content 
> intended for presentation to humans, it would be better to say that.  
> In any case, putting a MUST-level requirement on this seems strange.

Working Group Resolution (LC-2069):
We agree that there is no applicable mechanism to determine that the user
agent is a Web browser, and have removed any normative statement from the

The section was substantially reworded and now refers to the notion of
"Traditional Browsing".

The updated text is available at:


Your comment on 4.1.4 Serving Cached Responses:
> * Section 4.1.4 "Proxies should follow standard HTTP procedures in  
> respect to caching..."  This seems a strange way to phrase it, and I  
> don't think it's useful to use RF2616 language here.

Working Group Resolution (LC-2070):
We agreed and have reworded the section to remove the weird use of
normative terms to refer to RFC2616.

The updated text is available at:


Your comment on 4.1.5 Alteration of HTTP Header Values:
> * Section 4.1.5 Bullet points one and 3 are get-out-of-jail-free cards 
> for non-transparent proxies to ignore no-transform and do other anti- 
> social things. They should either be tightened up considerably, or  
> removed.

Working Group Resolution (LC-2071):
What is now section 4.2.3 makes it clear that no-transform must be

Bullets 1 and 3 only refer to alteration of the User-Agent and Accept-*
headers and not to transformation of the response.


Your comment on 4.1.5 Alteration of HTTP Header Values:
> * Section 4.1.5 "proxies should use heuristics including comparisons  
> of domain name to assess whether resources form part of the same "Web 
> site."  I don't think the W3C should be encouraging vendors to  
> implement yet more undefined heuristics for this task; there are  
> several approaches already in use (e.g., in cookies, HTTP, security  
> context, etc.); please pick one and refer to it specifically.

Working Group Resolution (LC-2073):
We are not aware of any satisfactory heuristics. We acknowledge the fact
that Transformation Deployments will need to adopt heuristics of some kind,
and that this must be left open.


Your comment on 4.1.5 Alteration of HTTP Header Values:
> * Section 4.1.5 What is a "restructured desktop experience"?

Working Group Resolution (LC-2072):
We agree and have added a term reference to the definition of
"restructuring" and a cross reference to the section that describes the
user selection of restructured experience.

The updated text is available at:


Your comment on Content Tasting:
> * Section Proxies (and other clients) are allowed to and do  
> reissue requests; by disallowing it, you're profiling HTTP, not  
> providing guidelines.

Working Group Resolution (LC-2074):
Based on our experience and feedback from servers whose operators take
strong exception to this practice, we think it's reasonable to advise
operators of CT-proxies of this situation. We're not prohibiting reissuing
requests, we're just observing that content providers don't like it.


Your comment on Avoiding "Request Unacceptable" Responses:
> * Section Again, not specifying the heuristics is going to  
> lead to differences in behaviour, which will cause content authors to 
> have to account for this as well.
> * Section "A proxy must not re-issue a POST/PUT request..." Is 
> this specific to POST and PUT, or all requests with bodies, or...?

Working Group Resolution (LC-2075):
We now limit the scope to HEAD GET and POST. We observe that duplicate
POSTS are seen "in the wild" and think it important to point out to
operators of content transformation proxies that this is problematical.

We acknowledge that not specifiying heuristics will lead to differences in
behaviour. However, this is something that content transformation providers
will need to do to provide the service they set out to provide.

The updated text is available at:


Your comment on Sequence of Requests:
> * Section Use of the term 'representation' is confusing here;  
> please pick another one.
> * Section Using the same headers is often not a good idea.  
> More specific, per-header advice would be more helpful.

Working Group Resolution (LC-2076):
Ref 'representation', we agree and have used the term "included
resources", as defined in the W3C mobileOK Basic Tests standard:

Ref per-header advice, we agree and have clarified that we are only
talking about keeping the User-Agent HTTP header field consistent.

The updated text is available at:


Your comment on Original Headers:
> * Section This is specifying new protocol elements; this is  
> becoming a protocol, not guidelines.

Working Group Resolution (LC-2077):
We are reflecting current practice as implemented by content
transformation proxies. It is not our intention to create a new protocol,
just to try to reduce the chaos that is currently perceived to be out

The newly introduced HTTP Header Fields have been provisionally registered
with IANA:


Your comment on Proxy Treatment of Via Header:
> * Section When a proxy inserts the URI to make a claim of  
> conformance, exactly what are they claiming -- all must-level  
> requirements are met? Should-level? What is the use case for this  
> information?

Working Group Resolution (LC-2078):
We agree and have clarified that inclusion of a Via comment of the form
indicated is not a conformance claim, but is an indication that the proxy
may restructure or otherwise modify content.

The updated text is available at:


Your comment on 4.2.1 Use of HTTP 406 Status:
> * Section 4.2.1 Requiring servers to respond with 406 is profiling  
> HTTP; HTTP currently allows the server to send a 'default'  
> representation even when the headers say that the client doesn't  
> prefer it.

Working Group Resolution (LC-2079):
We agree and have moved server behavior into an "Informative Guidance for
Origin Servers" non-normative appendix where we point out that servers
should consider using an HTTP 406 Status if a request cannot be satisfied.

The updated text is available at:


Your comment on 4.2.2 Server Origination of Cache-Control: no-transform:
> * Section 4.2.2 "Servers must include a Cache-Control: no-transform  
> directive if one is received in the HTTP request." Why?

Working Group Resolution (LC-2080):
We agree and have moved server behavior into an "Informative Guidance for
Origin Servers" non-normative appendix where we point out that servers
should consider including a Cache-Control: no-transform directive if one is
received as it may be an indication that the client does not wish to
receive a transformed response.

The updated text is available at:


Your comment on Use of Vary HTTP Header:
> * Section "Serves may base their actions on knowledge... but  
> should not choose an Internet content type for a response based on an 
> assumption or heuristics about behaiour of any intermediaries." Why
> not?

Working Group Resolution (LC-2081):
Guidelines for origin servers were switched to an informative appendix.
The text was clarified to point out that the Internet content type for a
response should be correct for the actual content, and not chosen on the
basis that the server suspects the proxy will not transform the content if
it receives such an Internet media type.

The updated text is available at:


Your comment on 4.3.2 Receipt of Warning: 214 Transformation Applied:
> * Section 4.3.2 Why can't proxies transform something that has already 
> been transformed?

Working Group Resolution (LC-2082):
We agree and have replaced the section with a section that notes that
intermediate proxies may add a Cache-Control: no-transform directive if
they want to inhibit further transformation.

The updated text is available at:


Your comment on 4.3.3 Server Rejection of HTTP Request:
> * Section 4.3.3 Sniffing content for error messages is dangerous, and  
> also unlikely to work. E.g., will you sniff for all languages and all 
> possible phrases? How will you avoid false positives? Remove this  
> section and require content providers to get it right. People may  
> still do this in their products, but there's no reason to codify it.

Working Group Resolution (LC-2083):
Sniffing content is an important part of the mechanism described in 4.1.5
so has to be mentioned here in some form. But we don't mean to propose this
as a fail safe mechanism, we merely mean to indicate that Content
Transformation proxies may need to employ heuristics to provide an improved
service for their users. Therefore we have removed any reference to
conforming servers.

The updated text is available at:


Your comment on 4.3.4 Receipt of Vary HTTP Header:
> * Section 4.3.4 What's the purpose behind this behaviour?

Working Group Resolution (LC-2084):
This section is part of the fail safe mechanism described in
Avoiding "Request Unacceptable" Responses. The reference to was
moved to the beginning of this section and the wording simplified.

The updated text is available at:

Received on Tuesday, 6 October 2009 15:49:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:51 UTC