- From: <fd@w3.org>
- Date: Tue, 06 Oct 2009 15:34:20 +0000
- To: casays <casays@yahoo.com>
- Cc: public-bpwg-comments@w3.org
Dear casays , 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/g7etib+9a0e@eGroups.com 2. http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/ ===== Your comment on 4.1.5 Alteration of HTTP Header Values: > 5) Section 4.1.5. > > Statement to be added: > > "The request MUST NOT be altered Whenever the URI of the > request indicates that the resource being accessed is able > to provide mobile-optimized content, e.g. the domain is > *.mobi, wap.*, m.*, mobile.*, pda.*, imode.*, iphone.*, > or the leading portion of the path is /m/ or /mobile/." > > Rationale: The guidelines make the assumption that all > requests may first undergo a transformation before possibly > falling back on a transformationless mode of operation. > This is unwarranted, and does not correspond to the way > many deployed proxies operate. > > Obviously, it is rather pointless to go all the way to > send a request to the server and wait for its response > in order to detect whether the resources accessed are for > mobile use, when it is already possible to do this by > inspecting the request of the client. The addition to the > guidelines covers this situation, and corresponds to the > state of the art in transformation proxies. It is also > consistent with the heuristic serving to determine whether > a response is already mobile-optimized. Following this > new guideline improves the performance of the entire > content delivery chain without loss of functionality, > and is congruent with the stated objective of the > guidelines of not disturbing mobile-optimized content. Working Group Resolution (LC-2049): The decision to transform requests does not depend on the URI pattern as discussed under 4.1.5: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-altering-header-values ---- Your comment on 4.1.5.5 Original Headers: > 2) Section 4.1.5.5 > > Statement to be inserted: > > "Except when explicitly provided for by RFC2616 to comply > with HTTP operations, a proxy MUST NOT delete HTTP header > fields received upstream from the client or downstream > from the server." > > Rationale: deployed transcoders have been known to filter > out entire HTTP fields, preventing servers from performing > adequate content delivery. In some environments, this > behaviour seems to have affected x-wap-profile in particular. > The statement makes it clear that deleting HTTP header fields > is in violation of the Web standards. Working Group Resolution (LC-2046): We agree and have added a "proxies MUST NOT delete header fields" guideline to the section. The updated text is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-original-headers ---- Your comment on 4.3.1 Receipt of Cache-Control: no-transform: > 1) Section 4.2.2: > > Statement to be inserted: > > "As per sections 13.5.2 and 14.9.5 of RFC2616, proxies MUST > NOT modify neither the header fields Content-Encoding, > Content-Range and Content-Type, nor the body originating > from a server that includes a no-transform directive in > its response. Proxies that do not follow this rule do not > conform to the HTTP protocol." > > Rationale: there actually are transcoders which, despite > no-transform directives, modify the body of the responses > from server. The statement reminds the users of such proxies > that they must be configured so as not to violate IETF > standards. Working Group Resolution (LC-2045): The comment applies to section 4.2.3 in the latest draft, where it is emphasize that proxies must not alter content other than to comply with transparent HTTP behavior as described in RFC2616. The updated text is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-cache-control-no-transform ---- Your comment on 4.3.6 Proxy Decision to Transform: > 4) Section 4.3.6. > > Complete the statement: > > "the URI of the response (following redirection > or as indicated by the Content-Location HTTP header) > indicates that the resource is intended for mobile > use (e.g. the domain is *.mobi, wap.*, m.*, mobile.*" > > ADD: , pda.*, imode.*, iphone.*, > > "or the leading portion of the path is /m/ or /mobile/);" > > Rationale: URL with pattern imode.* and pda.* have been in > use for many years, and unambiguously indicate sites that > are optimized for i-Mode devices or for PDA (Palm, PPC, > IEMobile). URL of the form iphone.* have started to appear, > providing experience specifically tailored to i-Phones; they > do not need, and should not be transformed either. Working Group Resolution (LC-2048): On LC-2048, As discussed, the sole remaining URI Pattern is listed in Appendix E ---- Your comment on D.4 Inter Proxy Communication: > 3) Cascaded proxies. > > a. Section 4.1.3 > > Statement to be inserted: > > "Whenever the requester is another transformation proxy, the > receiving proxy MUST treat it as a non-browser agent. The > receiving proxy SHOULD rely upon the presence of alternative > X-Device- HTTP fields and the values in the via HTTP field as > per 4.1.6.1 to detect that it is placed downstream from a > chain of proxies." > > > > b. Section 4.3.2 > > Statement to be inserted: > > "As per section 14.46 of RFC2616, 214 Transformation applied > MUST be added by an intermediate cache or proxy if it applies > any transformation changing the content-coding (as specified > in the Content-Encoding header) or media-type (as specified in > the Content-Type header) of the response, or the entity-body > of the response, unless this Warning code already appears in > the response. > > A proxy receiving a 214 code MUST NOT change it." > > > c. Section D.4 > > Eliminate entirely. > > Rationale: together with 4.3.1, 4.3.2, 4.1.2, 4.1.5.5, 4.1.6.1, > 4.3.6.1, these changed sections entirely solve the issue of cascading > proxies in a standards-compliant way. Working Group Resolution (LC-2047): Ref part a, we do not view the content transformation proxy as being a user agent in its own right, it is a proxy like any other. Knowing that it is upstream of other proxies doesn't alter its prescribed behaviour according to this document Ref part b, we think that this is defined in HTTP and that we don't need to elaborate on it unless there are specific examples of mis-operation that we can refer to Ref part c, we disagree and think that this is very complex and requires a substantial use case analysis to achieve a complete understanding. We think that a more complex HTTP vocabulary for inter proxy operation is likely to be required to achieve useful results, and we are not chartered to create technology of that kind ----
Received on Tuesday, 6 October 2009 15:34:29 UTC