List of comments on “Content Transformation Guidelines 1.0” (dated 1 August 2008)

There are 85 comments (sorted by their types, and the section they are about).

1-20 21-40 41-60 61-80 81-85

general comment comments

Comment LC-2043: Commenter: Mark Baker <distobj@acm.org> (archived message); Context: Document as a whole; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Here's my comments. In summary, the group really needs to decide
whether this is a guidelines document, or a protocol. It can't be
both. A lot of work remains.; Related issues: (space separated ids); WG Notes: ACTION-828 Proposed response: It's a guidelines document.; Resolution: Thanks for your comment. We have tried hard in the new revision to make sure that it is a guidelines document.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2097: OPES: Commenter: Barry Leiba <leiba@watson.ibm.com> on behalf of IAB (archived message); Context: Document as a whole; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
To the W3C Mobile Web Best Practices Working Group:

The Internet Architecture Board has reviewed the subject document, and notes that
it has previously reviewed related work done in the IETF in the Open Pluggable
Edge Services (OPES) Working Group. In its preview and review of OPES work, the
IAB expressed its concerns about privacy, control, monitoring, and accountability
of such services in RFC 3238 [ http://tools.ietf.org/html/rfc3238 ].

We have no specific architectural concerns with the "Content Transformation
Guidelines" document as written; it does seem to take into account the questions
raised during the OPES discussions. We would like, though, to make that explicit
by specifically documenting that you reviewed and considered the issues in RFC
3238.

Barry Leiba, for the Internet Architecture Board ( http://iab.org ); Related issues: (space separated ids); WG Notes: See http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Nov/0045.html; Resolution: Thanks very much for your comment. We make specific reference to OPES work in the new revision.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2025: Commenter: casays <casays@yahoo.com> (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
In general, I must state unequivocally that our experience with
current transformation proxies deployed throughout the world has
always been negative, since all proxies seem to transform original
mobile content regardless, with results ranging from passable to
outrageously unusable. The draft, while an interesting attempt to
bring some order in the wild practices that abound in the mobile Web,
is still vague and incomplete in several points, and thus, in its
present form, may not stem some of the more egregious forms of
transcoding we have witnessed so far.; Related issues: (space separated ids); WG Notes: Was: ACTION-829 I collected different comments on quality and purpose of the document from the comment list. Summary of all comments: 1) What is the purpose of the document, it does not deliver much guidance 2) The document is quite vague 3) The structure might be difficult to understand 4) Some sentences are not easy to understand. (Comment LC-2068, LC-2012) What can be done: 1) Before starting, create a common understandin about targets 2) Be more specific (LC 2038) 3) Add use cases and User Experience 4) Detail the "heuristics" (LC-2069, LC-2073) 5) Define when and how to change the UA string (LC 2054 is a great explanation) 6) Maybe we sould ad some flow chart starting from content tasting, ending with the requests and responses See: http://www.w3.org/2008/09/23-bpwg-minutes.html#item03; Resolution: We have attended to the main thrust of the comments here and the document reflects the commenters points more than it did at least; (Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-2065: Commenter: Dennis Bournique <db@wapreview.com> (archived message); Context: Document as a whole; Status:
assigned to Bryan Sullivan; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
My name is Dennis Bournique. I write about mobile browsing, primarily from a user perspective, at http://wapreview.com. I've done a little web development, mostly mobile specific sites, but I'm by no means an expert on the technical side of this issue.

Putting on my user hat, I'd like to make a request that the Content Transformation Guidelines include a requirement that content transformation proxies "must" provide end users (consumers of web content) with a way to turn off transformation both globally and on a site by site basis.

As an end user, Iâ€™ve experienced both the joys and the frustrations of using content transformation proxies.

In general, I believe in content transformation as a valuable tool to make web content, which would otherwise be difficult or impossible to use, available through the limited browsers of many mobile phones.

I have also been frustrated when a carrier or content provider unilaterally imposes content transformation with no way for me to disable it. I've been unable to access content through content transformation proxies that was previously available on the same device using a direct connection. This has happened both with installable content such as midlets and ringtones and also with pure html and xhtml pages, including mobile optimized pages and those that are not. I have also seen my secure end to end HTTPS traffic being forced through content transformation proxies, exposing it to the potential for a "man in the middle" attack.

I understand that the Guidelines are intended to prevent these sorts of problems by specifying when content transformation proxies must allow content to flow directly between server and user agent without modification. This is good, but no technical solution can ever be perfect. There will always be edge cases where content transformation does more harm than good. For this reason it is important that end users have the option to opt-out of content transformation.

I propose that the Guidelines be amended to include the following or similar language.

"...1. Content transformation proxies, if they are modifying traffic between a server and a user agent in any way, MUST provide a mechanism allowing the end user to resubmit the request and disable content transformation for the duration of the current session."

"...2. Content transformation proxies, must provide a means for end users of that proxy to disable all content transformation until they take explicit action to re-enable it."; Related issues: (space separated ids); WG Notes: Was: ACTION-830 See: http://www.w3.org/2008/09/02-bpwg-minutes.html#item04 Then: http://www.w3.org/2008/09/30-bpwg-minutes.html#item06 Final resolution: Move content from Appendix E to 4.3.6 somewhere and reword appropriately (and yes, partial to LC-2065); Resolution: We agree and have modified the wording, and have added an appendix that spells out where the various user preference clauses are to be found in the document. The appendix is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-Summary-User-Preference-Handling; (Please make sure the resolution is adapted for public consumption)

Comment LC-2089: Basic Content Tasting: Commenter: Heiko Gerlach <heiko.gerlach@vodafone.com>; Context: in; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Old text
Request resource with original headers

If the response is a 406 response:

If the response contains Cache-Control: no-transform, forward it

Otherwise re-request with altered headers

If the response is a 200 response:

If the response contains Vary: User-Agent, an appropriate link element or header, or Cache-Control: no-transform, forward it

Otherwise assess whether the 200 response is a form of "Request Unacceptable"

If it is not, forward it

If it is, re-request with altered headers

BUT WHERE IS THE TRANSCODING?
New Text:

Request resource with original headers

If the response is a 406 response:

If the response contains Cache-Control: no-transform, forward it

Otherwise re-request with altered headers

If the response is a 200 response:

If the response contains Vary: User-Agent, an appropriate link element or header, or Cache-Control: no-transform, forward it

Otherwise assess whether the 200 response is a form of "Request Unacceptable"

If it is not, TRANSCODE it

If it is, re-request with altered headers; Related issues: B.1
(space separated ids); WG Notes: Proposed resolution - resolve no.; Resolution: We don't specify that Transcoding must take place so we have not adopted this amendment.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2018: Commenter: C. M. Sperberg-McQueen <cmsmcq@acm.org> (archived message); Context: Content Transformation Guidelines 1.0; Status:
assigned to Sean Patterson; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Would it perhaps be better to give this specification a more informative
title, or at least some sort of informative subtitle?

The phrase "Content Transformation" sounds to an uninitiated reader
as if it could apply to anything from the use of the data manipulation
language (e.g. SQL) in a database management system, to the use of
XSLT, or the SAX or DOM interfaces, to transform XML documents, to
the use of dynamic HTML techniques to transform data in the browser.

Perhaps "Mobile Web Content Transformation"? Or "Content Transformation
for Mobile Presentation"? Surely there are ways of making it easier
for potential readers to see whether the document is relevant to their
concerns or not.

This isn't the first W3C spec to have such a generic title; the
experience
of the XML Schema specification, however, leads me to commend to you
urgently the wisdom of have a more specific, more informative, less
generic title for your document.

--Michael Sperberg-McQueen
W3C XML Activity; Related issues: (space separated ids); WG Notes: Was: ACTION-831 See: http://www.w3.org/2008/09/23-bpwg-minutes.html#item02 Final resolution: The title of the spec will be "Guidelines for Web Content Transformation Proxies"; Resolution: We agree and have changed the title of the document to "Guidelines for Web Content Transformation Proxies"; (Please make sure the resolution is adapted for public consumption)

Comment LC-2050: Commenter: casays <casays@yahoo.com> (archived message); Context: 2.2 Types of Transformation (Alteration of requests); Status:
assigned to Sean Patterson; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
1) Section 2.2.1:

The CTG distinguishes between retructuring, recoding and
optimization. This is a useful approach, and the distinction
could be used more systematically across the document. However,
without a formal definition of these terms, various parties
are left with too much leeway when classifying some operations
one or the other of the categories. This may entail inconsistencies
regarding the interpretation of the guidelines.

The guidelines should:
a) Define formally each of the three categories, possibly on
the basis of language theory. As an example, optimization seems
to be related to equivalent token streams (for textual content),
whereas recoding seems to deal with equivalent parse trees. Some
operations are reversible, others are not. The W3C is home to
technologies such as XSLT, so there should be competence there
to help ground definitions on solid formal concepts. Basing such
definitions on formal language theory is a suggestion, not a
requirement; other formally grounded definitions are possible.
b) Define exactly how to classify an operation that spans several
categories. As an example, converting HTML to XHTML while at the
same time eliminating comments and redundant white space should
amount to a recoding.; Related issues: (space separated ids); WG Notes: See: http://www.w3.org/2008/09/16-bpwg-minutes#item04 Final resolutions: - Re LC-2050 move definitions to scope to clarify that we are talking only about restructuring - re LC-2050 we don't intend to define these concepts any more formally than we do now; Resolution: Final resolutions: - Re LC-2050 move definitions to scope to clarify that we are talking only about restructuring - re LC-2050 we don't intend to define these concepts any more formally than we do now; (Please make sure the resolution is adapted for public consumption)

Comment LC-2067: Commenter: Mark Nottingham <mnot@mnot.net> (archived message); Context: 3.4 Content Deployment Conformance (Also concerns "3.5 Transformation Deployment Conformance"); Status:
assigned to François Daoust; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* 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?; Related issues: (space separated ids); WG Notes: See: http://www.w3.org/2008/09/16-bpwg-minutes#item03 Final resolution: re. LC-2067, state that conformance applies to SHOULD statements as well. A justification is required for each circumstance in which a SHOULD statement is not followed. Prepare an Implementation Conformance Statement to be filled out by Transformation Deployments willing to claim conformance to the spec. ACTION-846 on fd; Resolution: 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; (Please make sure the resolution is adapted for public consumption)

Comment LC-2003: Commenter: Luca Passani <passani@eunet.no> (archived message); Context: 4.1 Proxy Forwarding of Request; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Also, I see that CTG does not mention "whitelists". I think it should, since many transcoders manage that. The rule (consistently with the concept that transcoders must err on the side of not transcoding) should be that whitelists can only specify which potentially mobile sites can be forced to be trascoded (and not the other way around as happens to be common today, thus potentially forcing mobile developers to ask operators in different countries to whitelist their service, which is of course unacceptable).; Related issues: (space separated ids); WG Notes: Was: ACTION-833 See: http://www.w3.org/2008/09/23-bpwg-minutes.html#item06 and: http://www.w3.org/2008/10/20-bpwg-minutes.html#item04 Final resolution: - Make a note about the reasons for not referring to lists, of whatever hue, because the preumption about the internal operation of proxies is not in scope, as far as we are concenred these are "black boxes"; Resolution: We have had considerable discussion about "allow" and "disallow" lists and came to the conclusion that it was preferable to discuss a proxy's behavior rather than its (presumed) internal method of operation. Instead we refer to a notion that includes allow and disallow lists under 4.1.5 and 4.2.6. This approach allows us to specify that servers have a way of overcoming mis-configuration without recourse to administrative contact with any operator of a proxy and without specifying the exact configuration mechanism, which is usually not open to public inspection or evaluation. See updated sections 4.1.5: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-altering-header-values ... and 4.2.6: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-vary-header; (Please make sure the resolution is adapted for public consumption)

Comment LC-2019: Commenter: casays <casays@yahoo.com> (archived message); Context: 4.1.1 Applicable HTTP Methods; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
1) Section 4.1.1

Add to the section:

Proxies MUST NOT convert POST methods into GET ones, or vice-versa.

Rationale: This kind of transformation may make exchanges between
clients and servers inoperative. In particular, this kind of
substitution has been known to cause problems for content downloading
applications in the mobile Web.; Related issues: (space separated ids); WG Notes: Indeed proxies MUST NOT convert POST methods into GET ones, or vice-versa See: http://www.w3.org/2008/10/14-bpwg-minutes.html#item02 Final resolution: - re. LC-2019, amend text on conversion between HEAD and GET to say that other conversions are not allowed, and resolve partial to LC-2019; Resolution: Final resolution: - re. LC-2019, amend text on conversion between HEAD and GET to say that other conversions are not allowed, and resolve partial to LC-2019 The updated text is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-applicable-HTTP-methods; (Please make sure the resolution is adapted for public consumption)

Comment LC-2034: Commenter: Mark Baker <distobj@acm.org> (archived message); Context: 4.1.1 Applicable HTTP Methods; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
4.1.1 Applicable HTTP Methods

"Proxies should not intervene in methods other than GET, POST, HEAD and PUT."

I can't think of any good reason for that. If a request using an
extension method wants to avoid transformation, it can always include
the no-transform directive.; Related issues: (space separated ids); WG Notes: Further resolution: http://www.w3.org/2009/12/10-bpwg-minutes.html#added02 This "should not" note shows the scope of Content Transformation as discussed in the Guidelines Recommendation. It is not envisaged that a CT-proxy will intervene in a HTTP CONNECT for example. Or that a CT-proxy will adapt anything in any WebDAV methods. See: http://www.w3.org/2008/10/14-bpwg-minutes.html#item02 Final resolution: - ref LC-2034, we clarify that the scope of the document is limited to GET, POST, HEAD requests and their responses and resolve "no"; Resolution: 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; (Please make sure the resolution is adapted for public consumption)

Comment LC-2069: Commenter: Mark Nottingham <mnot@mnot.net> (archived message); Context: 4.1.3 Treatment of Requesters that are not Web browsers; Status:
assigned to Bryan Sullivan; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* 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.; Related issues: (space separated ids); WG Notes: See: http://www.w3.org/2008/10/20-bpwg-minutes.html#item03 Final resolution: - ref LC-2069. Resolved yes, with the replacement text: Before altering aspects of an HTTP request proxies ought to take account of the fact that HTTP is used as a transport mechanism for many other applications than "Traditional Browsing" and that alteration of HTTP requests for those applications can cause serious misoperation.; Resolution: 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; (Please make sure the resolution is adapted for public consumption)

Comment LC-2044: Commenter: Jim Jewett <jimjjewett@gmail.com> (archived message); Context: 4.1.3 Treatment of Requesters that are not Web browsers; Status:
assigned to Bryan Sullivan; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/

Section 4.1.3 ...

""'
The mechanism by which a proxy recognizes the user agent as a Web
browser should use evidence from the HTTP request, in particular the
User-Agent and Accept headers.
"""

Please clarify -- is this just the *existence* of those headers, or
the specific values? If it is the specific values, then please
provide some guidance (or a normative alternative) that new user
agents can use, before their names propagate to various whitelists.

-jJ; Related issues: (space separated ids); WG Notes: See: http://www.w3.org/2008/10/20-bpwg-minutes.html#added02 http://www.w3.org/2008/10/20-bpwg-minutes.html#item03 Final resolutions: - Ref LC-2044 Resolve yes, and change the text to say "*values* of User Agent and Accept headers", and clarify that we do not propose guidance for new user agents' use of these headers, it is out of scope ... followed by: - re LC-2044, resolution on LC-2069 removes the part that required clarification, resolve partial, we won't talk about "use of evidence"; Resolution: We agree that there was no existing mechanism by which proxies may positively determine that the requesting agent is a Web browser and have replaced the normative statement by an informative warning. As a consequence, the text does not mention "use of evidence" anymore. The updated text is available at: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-non-web-browsers; (Please make sure the resolution is adapted for public consumption)

Comment LC-2005: Commenter: EdPimentl <edpimentl@gmail.com> (archived message); Context: 4.1.5 Alteration of HTTP Header Values; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
The styleguide should spell out very clearly "The Transcoder is NOT
allowed to change the User-Agent String".; Related issues: (space separated ids); WG Notes: See: http://www.w3.org/2008/10/20-bpwg-minutes.html#item05 Final resolution: - WRT 4.1.5 Text remains substantially as is but is reinforced by saying that the CT proxy SHOULD NOT change headers and values other than User Agent and Accept(-*), MUST NOT delete headers and it MUST be psosible for the server to reconstruct the original UA originated headers by using X-Device etc.; Resolution: Section 4.1.5 on alteration of HTTP Header Field Values remains substantially as in the previous version of the document, but has been reinforced by saying that proxies must not delete headers and that is must be possible for the server to reconstruct the original User Agent originated headers by using the X-Device-* HTTP header fields: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-altering-header-values We have strengthened section 4.2.6 Receipt of Vary HTTP Header Field: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-vary-header We have also introduced new guidelines in section 4.2.2 User Preferences that forces proxies to provide a means for users to express their preferences for inhibiting content transformation: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-administrative-arrangements In addition, we have updated the conformance section to state that Transformation Deployments that choose to claim conformance with these guidelines need to spell out the circumstances in which they deviate from "should" clauses by providing a conformance statement that comes as a separate document referenced by the guidelines: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-transformation-deployment-conformance; (Please make sure the resolution is adapted for public consumption)

Comment LC-2053: Commenter: casays <casays@yahoo.com> (archived message); Context: 4.1.5 Alteration of HTTP Header Values; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
5) Section 4.1.5.

Statement to be added:

"In so far as the transformation carried out by the proxies is
to make content intended for a certain class A of devices
available to devices of another class B, then requests MUST NOT
be modified whenever a client of a certain class is accessing
content intended for its class.

If the class of request (either mobile-optimized or full-Web) is
not unambiguously determined from the URI pattern, the proxy
MUST take into account the original user-agent to avoid
unnecessary transformations."

Rationale: It is obviously pointless to transform full-Web
content accessed by full-Web capable devices (or vice-versa,
transforming mobile-optimized content for devices with mobile
browsers). Two cases illustrate the situation.
a) When full-Web devices such as advanced HTC PDAs, iPhones
or tablets access the Web, there is no guarantee that an
established server will include a no-transform directive; in
fact, it might explicitly leave it out to allow transformation
to cater for non-full-Web capable devices. Further, the
proposed heuristics will not work: the MIME types of returned
content will indicate full-Web content (e.g. text/html), as
well as the DOCTYPE (e.g. -//W3C//DTD HTML 4.01//EN).
b) When i-Mode terminal accessing i-Mode applications, there is
no guarantee that the corresponding servers return a no-transform
directive (since it is irrelevant for i-Mode applications).
Heuristics may not work either, since content is largely returned
as text/html, and without any DOCTYPE declaration.; Related issues: (space separated ids); WG Notes:; Resolution: Ref LC-2053, resolve partial and respond that we hope the current version of the document addresses this; (Please make sure the resolution is adapted for public consumption)

Comment LC-2071: Commenter: Mark Nottingham <mnot@mnot.net> (archived message); Context: 4.1.5 Alteration of HTTP Header Values; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* 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.; Related issues: (space separated ids); WG Notes: See: http://www.w3.org/2008/10/20-bpwg-minutes.html#item05 Final resolution: - WRT 4.1.5 Text remains substantially as is but is reinforced by saying that the CT proxy SHOULD NOT change headers and values other than User Agent and Accept(-*), MUST NOT delete headers and it MUST be psosible for the server to reconstruct the original UA originated headers by using X-Device etc.; Resolution: 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.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2073: Commenter: Mark Nottingham <mnot@mnot.net> (archived message); Context: 4.1.5 Alteration of HTTP Header Values; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
* 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.; Related issues: (space separated ids); WG Notes: RESOLUTION: Ref LC-2073, resolve no, we are not aware of any satisfactory heuristics, but understand that CT Proxy vendors will need to adopt heuristics of some kind so we have no choice but to leave it open; Resolution: 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.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2017: Commenter: Terren Suydam <terren@singleclicksystems.com> (archived message); Context: 4.1.5 Alteration of HTTP Header Values; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Hello,

As the technical lead for SingleClick Systems mobile development, I'm
writing to protest the W3C's failure to provide a clear rule against the
modification of the User-Agent header.

As mobile developers, my team spends a lot of time creating the mobile
experience *we* want our users to see. If our users are subjected to the
confusing experience of transcoding, we lose money.

I urge the W3C to adopt the standards set forth by Luca Passani's
Manifesto, of which I'm sure you're aware.

Sincerely,
Terren Suydam; Related issues: (space separated ids); WG Notes: See: http://www.w3.org/2008/10/20-bpwg-minutes.html#item05 Final resolution: - WRT 4.1.5 Text remains substantially as is but is reinforced by saying that the CT proxy SHOULD NOT change headers and values other than User Agent and Accept(-*), MUST NOT delete headers and it MUST be psosible for the server to reconstruct the original UA originated headers by using X-Device etc.; Resolution: Section 4.1.5 on alteration of HTTP Header Field Values remains substantially as in the previous version of the document, but has been reinforced by saying that proxies must not delete headers and that is must be possible for the server to reconstruct the original User Agent originated headers by using the X-Device-* HTTP header fields: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-altering-header-values We have strengthened section 4.2.6 Receipt of Vary HTTP Header Field: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-vary-header We have also introduce new guidelines in section 4.2.2 User Preferences to force proxies to provide a means for users to express their preferences for inhibiting content transformation: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-administrative-arrangements In addition, we have updated the conformance section to state that Transformation Deployments that choose to claim conformance with these guidelines need to spell out the circumstances in which they deviate from "should" clauses by providing a conformance statement that comes as a separate document referenced by the guidelines: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-transformation-deployment-conformance; (Please make sure the resolution is adapted for public consumption)

Comment LC-1996: Commenter: Luca Passani <passani@eunet.no> (archived message); Context: 4.1.5 Alteration of HTTP Header Values; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
- the styleguide should spell out very clearly "The Transcoder is NOT
allowed to change the User-Agent String".
I understand that the current document says "do not change headers", but at the same time, there are clauses ("the user has specifically requested a restructured desktop experience") which would allow abusive transcoders to find an excuse and keep being abusive of the rights of content owners. Preventing transcoders from changing the UA string is an effective way to avoid this abuse.; Related issues: (space separated ids); WG Notes: See: http://www.w3.org/2008/10/20-bpwg-minutes.html#item05 Final resolution: - WRT 4.1.5 Text remains substantially as is but is reinforced by saying that the CT proxy SHOULD NOT change headers and values other than User Agent and Accept(-*), MUST NOT delete headers and it MUST be psosible for the server to reconstruct the original UA originated headers by using X-Device etc.; Resolution: Section 4.1.5 on alteration of HTTP Header Field Values remains substantially as in the previous version of the document, but has been reinforced by saying that proxies must not delete headers and that is must be possible for the server to reconstruct the original User Agent originated headers by using the X-Device-* HTTP header fields: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-altering-header-values We have strengthened section 4.2.6 Receipt of Vary HTTP Header Field: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-receipt-of-vary-header We have also introduces new guidelines in section 4.2.2 User Preferences that forces proxies to provide a means for users to express their preferences for inhibiting content transformation: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-administrative-arrangements In addition, we have updated the conformance section to state that Transformation Deployments that choose to claim conformance with these guidelines need to spell out the circumstances in which they deviate from "should" clauses by providing a conformance statement that comes as a separate document referenced by the guidelines: http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-transformation-deployment-conformance; (Please make sure the resolution is adapted for public consumption)

Comment LC-2038: Commenter: Mark Baker <distobj@acm.org> (archived message); Context: 4.1.5 Alteration of HTTP Header Values; Status:
assigned to Jo Rabin; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
The rest of the 4.1.5.* sections all seem to be basically "Here's some
things that some proxies do". By listing them, are you saying these
are good and useful things, i.e. best practices? If so, perhaps that
should be made explicit.; Related issues: (space separated ids); WG Notes: LC-2038 - is it a list of Best Practices? Be explicit it that's the case RESOLUTION: ref LC-2038, resolve partial. Answer "no, these are not best practices, but guidelines". Don't change the text.; Resolution: The document is not a set of best practices but a set of guidelines.; (Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-60 61-80 81-85

Add a comment.