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

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 Monday, 2 June 2008 19:13:48 UTC