- 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
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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/. 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 Track. Thanks, 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 accordingly. The updated text is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-types-of-proxy ---- 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-transformation-deployment-conformance ---- 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-request-no-transform ---- 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 section. The section was substantially reworded and now refers to the notion of "Traditional Browsing". The updated text is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-non-web-browsers ---- 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-serving-cached-responses ---- 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 respected: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-cache-control-no-transform 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-altering-header-values ---- Your comment on 4.1.5.1 Content Tasting: > * Section 4.1.5.1 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 4.1.5.2 Avoiding "Request Unacceptable" Responses: > * Section 4.1.5.2 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 4.1.5.2 "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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-avoiding-request-unacceptable ---- Your comment on 4.1.5.4 Sequence of Requests: > * Section 4.1.5.4 Use of the term 'representation' is confusing here; > please pick another one. > > * Section 4.1.5.4 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: http://www.w3.org/TR/mobileOK-basic10-tests/#included_resources 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-sequence-of-requests ---- Your comment on 4.1.5.5 Original Headers: > * Section 4.1.5.5 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 there. The newly introduced HTTP Header Fields have been provisionally registered with IANA: http://www.iana.org/assignments/message-headers/prov-headers.html ---- Your comment on 4.1.6.1 Proxy Treatment of Via Header: > * Section 4.1.6.1 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-via-headers ---- 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-server-use-of-406 ---- 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-cache-control-no-transform ---- Your comment on 4.2.3.1 Use of Vary HTTP Header: > * Section 4.2.3.1 "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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-use-of-vary-header ---- 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-proxy-use-of-no-transform ---- 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: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-unacceptable-response ---- 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 4.1.5.2 Avoiding "Request Unacceptable" Responses. The reference to 4.1.5.2 was moved to the beginning of this section and the wording simplified. The updated text is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-vary-header ----
Received on Tuesday, 6 October 2009 15:49:35 UTC