RE: ACTION-735: linearization and zooming capabilities and support for a wide range of formats

Comments inline below.

> -----Original Message-----
> From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Jo Rabin
> Sent: Wednesday, April 16, 2008 11:59 AM
> To: Francois Daoust; public-bpwg-ct
> Subject: RE: ACTION-735: linearization and zooming capabilities and
> support for a wide range of formats
> 
> 
> 
> 
> > -----Original Message-----
> > From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-
> request@w3.org]
> > On Behalf Of Francois Daoust
> > Sent: 16 April 2008 09:16
> > To: public-bpwg-ct
> > Subject: ACTION-735: linearization and zooming capabilities and support
> > for a wide range of formats
> >
> >
> > Context
> > -------
> > This was initially raised by Sean [1], and I took an action yesterday to
> > bring the discussion and propose some solutions on the mailing-list, so
> > here we go...
> >
> > In 4.1.2 Proxy Decision to Transform the request [2], there's a sentence
> > that states:
> > "Knowing that the browser has available a linearization or zoom
> > capability and/or supports a broad range of content formats the proxy
> > SHOULD NOT restructure or recode content."
> >
> > I don't really know what triggered that statement in the first place. If
> > a wise elder who remembers all the tiny details of the history of the
> > doc can be of any help... :-)
> >
> Well it must have been me that typed it. Though I don't mind being called
> wise I'd prefer not to be called elder, no matter how true it is :-(
> 
> >
> > Comments
> > --------
> > 1. First comment is that "restructure" and "recode" are alteration of
> > the response, and not of the request, as defined as 2.2, so the
> > statement would probably better be thought as:
> > "Knowing that the browser has available a linearization or zoom
> > capability and/or supports a broad range of content formats the proxy
> > SHOULD NOT alter the request and SHOULD NOT restructure or recode the
> > response."
> >
> I think that is the idea, though as pointed out the "don't change the
> headers bit" belongs here, whereas the "don't change the response" bit
> belongs lower down.
> 
> >
> > 2. What are we trying to say here? I suppose it means that for
> > "advanced" browsers, the CT-proxy should behave transparently with both
> > the request and the response, because the browser probably knows better.
> > I'm not sure how one defines an "advanced" browser today... and
> > tomorrow. What would this sentence look like in 3 years from now?
> >
> In three years time all networks will be free, all latency will have
> disappeared and all mobile browsers will be perfect with holographic
> displays and indefinite battery life.
> 
> I don't think we need to say "advanced" I think we need to say that the
> browser aims to overcome the limitations of the display specifically for
> the purpose of rendering desktop oriented Web content. I think it's those
> browsers that should set the no-transform option, for avoidance of doubt,
> but in the interim, they don't.
> 
> > As for today, as Sean said during the call, an advanced browser may not
> > implement a functionality where a CT-proxy may help. A (bad) example of
> > that:
> > - the Safari browser on the iPhone currently doesn't support SVG
> > - the CT-proxy could convert SVG images to PNG images.
> > -> The statement seems to say that the CT-proxy shouldn't do that.
> > (the example is bad, because SVG is not exactly the most widely used
> > format ever...)
> >
> 
> I think that the server should in any case offer a fall back option. If it
> doesn't, is it fair enough for the CT proxy to offer one? At users choice,
> I guess. The point though, is that in this case the CT proxy is not
> offering to restructure, it is offering to recode. Well, there are
> probably examples which go beyond that ...
> 

Maybe we should ease the restriction on recoding in this statement.  Allow recoding to formats the client doesn't support.

In addition there can be other factors that affect whether it makes sense to recode or restructure.  A user with an advanced phone on a slow network (possible in the U.S., anyway) might want images recoded so they use less bandwidth.  Or maybe restructure the page into segments so it doesn't take so long to download the entire page.  As Jo mentioned, this kind of thing can come down to the user's choice.

> >
> > 3. Another thing to consider: we have a strong statement before that one
> > that says
> > "Proxies should not alter HTTP requests unless:
> > - unaltered headers would result in the user's request being rejected by
> > the origin server
> > - the user has specifically requested a restructured version of a
> > desktop presentation"
> >
> > What does the request part of the "advanced" browser statement add to
> > this one, since the decision to alter the HTTP request doesn't depend on
> > the device's capabilities?
> > (We may still want to keep the statement for the response though)
> >
> True, good point.
> 
> >
> >
> > Possibility 1: we keep something along these lines
> > -------------
> > We could do (a combinaison of):
> > a) keep a statement in 4.1.2 that says the CT-proxy SHOULD NOT alter an
> > HTTP request if it detects the device is an advanced one.
> > -> -1 based on 3. above.
> -1 to not removing the statement. [or perhaps +1 to removing it from the
> header modification bit would be a bit clearer]
> >
> > b) move the statement to 4.4 Proxy Response to User Agent to say the
> > CT-proxy SHOULD NOT restructure and recode the response in that case.
> > -> +1. Even with 2. above, I still think it's a good thing to say
> > "advanced" browsers should be given the possibility to do their job.
> > It's a weak +1 though. Something like a +0.5.
> I agree. Though more as a +0.9
> >
> > c) complete the "any knowledge it has of user agent capabilities" bullet
> > in 4.1.2 with examples that include linearization, zooming and support
> > for a wide range of formats.
> > -> 0. Although I love examples, I'm not a big fan of completing all our
> > bullets and statements with examples as it could "hide" the underlying
> > statements. But then...
> >
> I think this is the right place for it.
> 

I agree the "advanced browser" issue needs to be addressed somewhere in the guidelines.  However, these browsers have a wide range of capabilities, so I don't think we should rule out all transformations just because they have some linearization or zoom capabilities.  It depends on the browser (or more accurately, the device context) just like with less capable browsers.


> >
> > Possibility 2: we remove that notion altogether
> > -------------
> > -> -0.5 ;-)
> 
> I think it needs to be there because the capability is under the most
> direct control of the user.
> 
> >
> >
> > References
> > ----------
> > [1] http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Apr/0020.html
> > [2]
> > http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-
> > drafts/Guidelines/080410#sec-decision-to-transform
> >
> >
> > Hope this helps!
> > François.
>

Received on Friday, 18 April 2008 21:29:26 UTC