Re: 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) ( LC-2323 LC-2316 LC-2317 LC-2320 LC-2321 LC-2318 LC-2319 LC-2322)

 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