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


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


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?

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


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)



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.

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.

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


Possibility 2: we remove that notion altogether
-------------
-> -0.5 ;-)


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 Wednesday, 16 April 2008 08:16:33 UTC