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

I'm not sure I completely agree.

We only mention user preferences where they directly apply, not where 
they may override that of the server, and I think that's good as it is, 
provided we're clear in 3.2.4 (and in 3.2.3) that it applies to all 
servers guidelines (and thus, mostly, to the Cache-Control: no-transform 
directive).

If we include them in 4.1.1 and 4.4, we'll get sentences such as:
"If the response includes a Cache-Control: no-transform directive then 
the response MUST remain unaltered (...) except if the user expressly 
said he wants transformation".
I think it creates more confusion than clarity, IMO.

[For the HTTPS case, we're not really talking about the possibility that 
the user expressed preferences, but as a mandatory feature that allows 
the user to decide whether an HTTPS content may be transformed or not.]

Francois.


Sean Patterson wrote:
> OK, it wasn't clear to me that 3.2.3 (and I suppose 3.2.4) applied to
> the Cache-control: no-transform situation.  The other cases you mention
> (alteration of headers and HTTPS--cases a and c below--explicitly
> mention that user preferences will be taken into account when the CT
> proxy decides whether to transform or not (or alter headers)).  There is
> no such mention of user preferences for Cache-control: no-transform.
> Perhaps we should do this to be clear and consistent.  (Should probably
> do this in both 4.1.1 and 4.4).
> 
> Sean
> 
>> -----Original Message-----
>> From: Francois Daoust [mailto:fd@w3.org]
>> Sent: Monday, May 26, 2008 4:10 AM
>> To: Sullivan, Bryan
>> Cc: Sean Patterson; public-bpwg-ct
>> Subject: 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 Tuesday, 10 June 2008 13:30:50 UTC