Re: CT Guidelines and Cache-Control: no-transform

This is already covered by the guidelines, IMO.
[For the sake of clarity, I won't end up next sentences with "IMO", but 
note the whole thing is IMO ;-)]

As stated in current 3.2.3 "Control by Administrative or Other 
Arrangements": "the preferences of users and of servers MAY be 
ascertained by means outside the scope of this document".

This includes the fact the CT function [in scope] is just one aspect of 
the proxy layer [out of scope], and addresses points 2 
(headers/footers), 4 (billing) and 5 (antivirus-like behavior) below, 
mostly through terms and conditions agreed between the user and the 
Content Transformation service provider.

Even though it's a bit frustrating to see that most of the discussions 
we had in the past few months were motivated by potential restrictions 
on what the CT proxy may do, we're still trying to enable access to 
non-mobile-aware web sites, and in practice didn't end up with many 
restrictions.

In short:
a) alteration of an HTTP request is not a "good" use of HTTP. 
Restrictions were needed, but we still acknowledged the fact that 
alterations of the headers were sometimes compulsory.

b) content providers need a way to switch off the content transformation 
process. That's the "Cache-Control: no-transform" directive. In our 
CT-only box, it means "no transformation, period". But the above 
mentioned 3.2.3 still applies.

c) apart from this no-transform directive and the HTTPS case, there is 
no restriction on the alteration of the response. We mention heuristics, 
but leave the decision open, thereby allowing for future improvements in 
content transformation.

I don't think we should lessen the meaning of the "Cache-Control: 
no-transform" directive. It is not widely used in "non-mobile-aware" web 
sites either, is it? But we may want to emphasize that it's a strong 
directive and that it should be used with care.


Sean, points 1 and 6 below are covered by the "serious mis-operations of 
the user agent" case, but I agree, the guidelines would most probably 
benefit from more examples...

Points 3 (and part of point 2) on the consistency of the user experience 
is a tricky one, but that's already the case with "regular" 
desktop-browsing: one browses a portal, clicks on a link, and is 
redirected to some other site with a completely different layout.

Francois.



Sullivan, Bryan wrote:
> Sean,
> I agree with your comments. This gets back to my earlier comments that 
> the purpose/scope of the CT guidelines should be how to do effective 
> content transformation to enable acceess to non-mobile-aware web sites. 
> Any extra value-added or policy-based aspects of the CT proxy's function 
> should be out of scope. The CT guidelines should focus on getting CT 
> function to work, and not stray into restrictions on what a CT proxy can 
> be used for. After all, the CT function is likely just one aspect of 
> the a proxy layer in a mobile browsing service architecture. I do 
> believe the CT guidelines should state what it expects to be "normal" 
> behavior, but recognize that other valid objectives may modify that 
> normal behavior per the requirements of a particular deployment.
>  
> Best regards,
> Bryan Sullivan | AT&T
> ------------------------------------------------------------------------
> *From:* public-bpwg-ct-request@w3.org 
> [mailto:public-bpwg-ct-request@w3.org] *On Behalf Of *Sean Patterson
> *Sent:* Friday, May 23, 2008 2:08 PM
> *To:* public-bpwg-ct
> *Subject:* CT Guidelines and Cache-Control: no-transform
> 
> In the current draft of the CT Guidelines, we have the following 
> paragraphs at the end of section 4.4:
> 
> ------
> 
> If the response includes a Cache-Control: no-transform directive then 
> the response *must* remain unaltered other than to comply with 
> transparent HTTP behavior and other than as noted below.
> 
> If the proxy determines that the resource as currently represented is 
> likely to cause serious mis-operation of the user agent then it *may*, 
> with the users explicit prior consent, warn the user and provide links 
> to both transformed and unaltered versions of the resource.
> 
> ------
> 
> I wonder if this might be too strict.  Here are a few reasons:
> 
> 1) A web page that is too large for the memory of the device could cause 
> it to crash or hang.  Segmentation into smaller pages would be a useful 
> transformation in this case.  This may be covered by the second 
> paragraph; maybe an example would make this clearer.
> 
> 2) CT proxy operators frequently like to add headers and/or footers to 
> web pages that contain useful tools such as a link to the home page, a 
> link to bookmarks, a "Go To URL" box, etc.  If some pages had headers 
> and/or footers and some pages did not, this could be confusing and 
> frustrating to users.
> 
> 3) With a CT proxy that does URL rewriting (as opposed to a CT proxy 
> that is set up as an HTTP proxy), once a user goes to a page that is not 
> transformed (i.e., does not have its URLs rewritten), it may not be 
> obvious to the user how to return to using the CT proxy.  The links on 
> the page no longer point to the CT proxy.
> 
> 4) There could also be a billing issue with a URL-rewriting CT proxy 
> that does not transform a page.  Frequently, operators of CT proxies 
> bill differently for transactions that go through the CT proxy and 
> transactions that do not (billing is based on domain).  An example would 
> be a flat monthly fee for transactions that go though the CT proxy and 
> billing by the KB for transactions that do not go through the CT proxy.  
> Once a user receives a page that doesn't have rewritten URLs, he or she 
> could incur larger data charges for Web usage without realizing it.
> 
> 5) One could also envision some security advantages to allowing URLs to 
> be rewritten even for "no-transform" pages.  For example, phishing pages 
> or viruses could be detected by the CT proxy and blocked.
> 
> 6) Sometimes images or other media are marked no-transform.  If the 
> client can't handle the image format delivered by the content server 
> (the content server would have to ignore the Accept header in this 
> case), it may make more sense to transform the image into an understood 
> format instead of delivering the unsupported image to the client.
> 
> Obviously if it was decided that a no-transform page should be 
> transformed, the goal would be to keep the formatting and visible 
> content of the page identical to the original page (between the headers 
> and/or footers).  You’d also probably want to get the user’s permission 
> to do this.
> 
> 
> Sean
>

Received on Monday, 26 May 2008 09:10:20 UTC