- From: <fd@w3.org>
- Date: Thu, 11 Feb 2010 22:32:01 +0000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: public-bpwg-comments@w3.org,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 Guidelines for Web Content Transformation Proxies 1.0 published on 6 Oct 2009. 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/2010/WD-ct-guidelines-20100211/. Please review it carefully and let us know by email at public-bpwg-comments@w3.org if you agree with it or not before 11 March 2010. 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/3BD9BF23-5F9E-42DC-AA1A-C2EB6FAD46F8@mnot.net 2. http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/ ===== Your comment on the document as a whole: > Overall, I'd say that the document quality is still marginal at best; it > uses a lot of imprecise terminology and muddies the waters more than it > clarifies things. Many (if not most) of its requirements aren't > testable. > > My concern is that Recommending this document will cause more harm than > good to the Web overall (even if it does represent a consensus of sort > among a more limited community). Working Group Resolution (LC-2323): We have added text to clarify and precise some of the guidelines you referred to in your reply (see responses to the relevant messages). We do not think that this document should be viewed as the final word on the subject, though we still think it is a valuable contribution. ---- Your comment on 4.1.1 Applicable HTTP Methods: > * 4.1.1 "Proxies should not intervene in methods other than GET, POST, > HEAD." "Intervene" is vague here; does it mean that they're not allowed > to change the requests, but are allowed to change the responses to them? > Or they're not allowed to transform neither the request nor the > response? Working Group Resolution (LC-2316): We agree and have removed the restriction on specific HTTP methods in 4.1.1 and 4.2.1. It was unnecessary to mention this in this document which is scoped to traditional Web browsing. ---- Your comment on 4.1.4 Serving Cached Responses: > * 4.1.4 "so should notify the user that this is the case" -- how? Using > a Warning header? Are they required to populate the Age header, so that > the user can calculate whether it's stale themselves? Working Group Resolution (LC-2317): We agree and have added a definition of user interaction that details the communication channel that must be used. We have re-worded the guidelines that refer to user interaction as a consequence. ---- Your comment on 4.1.5 Alteration of HTTP Header Field Values: > * 4.1.5 "the request is part of a sequence of requests to the same Web > site and either it is technically infeasible not to adjust the request > because of earlier interaction, or because doing so preserves > consistency of user experience." This seems like a hole that a proxy > vendor can drive a truck through... are you serious? Working Group Resolution (LC-2320): We agree and have removed mentions of "technically infeasible" and "preserves consistency of user experience". The bullet point now reads: "the request is part of a sequence of requests comprising either included resources or linked resources on the same Web site (see 4.1.5.4)". Section 4.1.5.4 contains the normative guidelines relevant to this case. ---- Your comment on 4.1.5 Alteration of HTTP Header Field Values: > * 4.1.5.1 "The theoretical idempotency of GET requests is not always > respected by servers. In order, as far as possible, to avoid > misoperation of such content, proxies should avoid issuing duplicate > requests and specifically should not issue duplicate requests for > comparison purposes." > > Existing proxies can and do already retry GETs; I'm not sure who you're > trying to protect here. Working Group Resolution (LC-2321): We have removed the mention of the "theoretical idempotency of GET requests" and clarified the text in relation with the mechanisms described in 4.1.5 and 4.2.6. However, we still advise to reduce the number of requests sent for the same resource where possible. ---- Your comment on 4.1.5 Alteration of HTTP Header Field Values: > * 4.1.5 It needs to be explicitly pointed out here that the > modifications listed are not allowed when CC: no-transform is present in > the request. Otherwise, the relative precedence of the requirements in > the document is too imprecise. Working Group Resolution (LC-2318): We agree and have clarified the text. ---- Your comment on 4.1.5 Alteration of HTTP Header Field Values: > * 4.1.5 "Aside from the usual procedures defined in [RFC 2616 HTTP] > proxies should not modify the values" -- I have a hard time parsing > this. Do you mean "In addition to the requirements of [RFC2616]..." ? Working Group Resolution (LC-2319): We agree and have reworded the text to say "Other than the modifications required by RFC2616" ---- Your comment on 4.2.7 Link to "handheld" Representation: > * 4.2.7 Link to "handheld" representation -- you're requiring proxies to > "process" (whatever that means) handheld links, even if the client isn't > handheld? Working Group Resolution (LC-2322): We have clarified the guideline to apply only to user agents that are "handheld". ----
Received on Thursday, 11 February 2010 22:32:05 UTC