Public document·View comments·Disposition of Comments·
Mobile Web Best Practices Working Group Other specs in this tool Mobile Web Best Practices Working Group's Issue tracker
In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.
In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.
Commentor | Comment | Working Group decision | Commentor reply |
---|---|---|---|
LC-2090
Luca Passani <passani@eunet.no> (archived comment) |
|
The goals of this specification is to provide guidance to Content Transformation proxies and Content Providers as to how inter-work when delivering Web content. In other words, the guidelines are focused on defining means for the various actors of the delivery chain to communicate their intent and expectations. The details of how a Content Transformation proxy performs restructuring operations is out of scope of this specification. The notion of user experience is by essence vague, and one design may be regarded as providing a better user experience by some and a lesser one by someone else. The Working Group notes that alteration and thus injection of extra content is forbidden in responses served with a Cache-Control: no-transform. Content Providers who do not want their content to be altered in any way should use this directive. |
no |
LC-2034
Mark Baker <distobj@acm.org> (archived comment) |
|
This "should not" note shows the scope of Content Transformation as discussed in the Guidelines Recommendation. It is not envisaged that a content transformation proxy will intervene in a HTTP CONNECT for example. Or that a content transformation proxy will transform anything in any WebDAV methods. In fact we don't envisage any intervention in PUT either, so we will drop this to clarify that the scope of the document is limited to web browsing, using GET, POST & HEAD requests and their responses. The updated text is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-applicable-HTTP-methods |
no |
LC-2036
Mark Baker <distobj@acm.org> (archived comment) |
|
Based on our experience and feedback from servers whose operators take strong exception to the practice of repeating GETs, we think it is reasonable to advise content transformation proxies operators of this situation. We're not prohibiting reissuing requests, we're just observing that content providers don't like it. | no |
LC-2071
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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. |
no |
LC-2073
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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. | no |
LC-2074
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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. | no |
LC-2075
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2077
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2083
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2067
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2069
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2072
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2076
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2078
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2079
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2080
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2082
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2084
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2066
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |
LC-2068
Mark Nottingham <mnot@mnot.net> (archived comment) |
|
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 |
no |