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).


> -----Original Message-----
> From: Francois Daoust []
> 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",
> 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
> 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
> 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
> but leave the decision open, thereby allowing for future improvements
> 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"
> 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
> 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
> 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
> > the purpose/scope of the CT guidelines should be how to do effective
> > content transformation to enable acceess to non-mobile-aware web
> > Any extra value-added or policy-based aspects of the CT proxy's
> > 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
> > 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
> > 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:*
> > [] *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
> > 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
> > likely to cause serious mis-operation of the user agent then it
> > with the users explicit prior consent, warn the user and provide
> > 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
> > it to crash or hang.  Segmentation into smaller pages would be a
> > 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
> > web pages that contain useful tools such as a link to the home page,
> > link to bookmarks, a "Go To URL" box, etc.  If some pages had
> > 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
> > 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
> > 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
> > be a flat monthly fee for transactions that go though the CT proxy
> > billing by the KB for transactions that do not go through the CT
> > Once a user receives a page that doesn't have rewritten URLs, he or
> > could incur larger data charges for Web usage without realizing it.
> >
> > 5) One could also envision some security advantages to allowing URLs
> > be rewritten even for "no-transform" pages.  For example, phishing
> > 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
> > 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
> > and/or footers).  You'd also probably want to get the user's
> > to do this.
> >
> >
> > Sean
> >

Received on Monday, 2 June 2008 19:13:48 UTC