Re: CT: mandating respect of some heuristics

On 28 Jan 2009, at 15:00, Francois Daoust wrote:

>
> Hi,
>
> Here is a summary of what I think the current discussion on  
> ISSUE-286 is at. I say "we" below, but that should be read as my  
> biased view of it :-)
>
> The idea is to forbid content transformation for some of the "mobile  
> heuristics" we currently have, when an explicit "mobile" flag is set  
> in an HTTP response. Pending the resolution of the questions  
> mentioned below, I haven't heard any objection to the idea.
>
> The list of explicit heuristics is:
> * mobile doctypes (XHTML MP and Basic, WML, iMode)
> * <link rel="alternate" media="handheld" href=""/> and possibly  
> <link rel="alternate" media="all" href=""/> (where the value of  
> "href" is a same-document reference)
> * Content-Type in current appendix E [1], save "application/xhtml+xml"
> * possibly a mobileOK claim if that gets defined in time for this  
> document
> Slight adjustments may have to be done in that list. There are no  
> other identified explicit mobile flags.
>
> We identified a few cases where transformations might still be  
> useful when mobile content is served, for instance to remove  
> comments that may appear before an XML declaration, and that would  
> prevent content rendering on the device. There is a general  
> agreement that we are at the "SHOULD" level here and not at the  
> "MUST" level.
> We do not intend to provide a list of possible exceptions. The  
> addition of header/footer and more generally any transformation done  
> on a regular basis (i.e. regardless of the response) are not valid  
> exceptions.
>
>

One question.  This assumes that proxies can be turned off.  There are  
mobile browsers that can't turn off the proxy as they wouldn't work  
without it, such as Opera Mini, TeaShark, Skyfire, Bolt, et al.  We  
obviously don't want to be seen as just specifying for the "rich mans  
web", that can afford mobiles capable of using a full smart phone  
level browser.  We can either specify that these browsers can  
transform the content if there is no other way to display the content,  
or we can forbid the browser/proxy to display the page as the browser  
vendors will just ignore you and the document.


> There are two open questions to which I add a minor third one:
>
> 1. Whether content transformation proxies that operate in "link- 
> mode" (i.e. all URIs are re-written to go through the proxy) are  
> allowed to rewrite links in mobile content, so that they may still  
> provide transformation services for pages that are linked from the  
> mobile page.
>
> I note that such proxies also lose the possibility to propose their  
> services when they receive a response with a "Cache-Control: no- 
> transform" directive, since they cannot rewrite links in such cases  
> either. I agree that this situation is not exactly the same. I  
> wonder if there are many proxies around that operate in "link-mode"  
> and need to be compliant with the guidelines?
>
> Since this is a transformation that would be done on a regular  
> basis, I do not think it fits as a possible exception to the  
> "SHOULD" clause. Besides, if we add that as a normal exception, then  
> the SHOULD significantly loses its meaning.
>
> The proposal could be to complete the guideline with an explicit  
> exception for links rewriting for proxies that operate in that mode.
>
>
> 2. Whether users may express their preference to have mobile pages  
> still transformed.
>
> This is actually already covered by the text of current section  
> 4.2.2 [2] that says:
> "Proxies must provide a means for users to express preferences for  
> inhibiting content transformation. Those preferences must be  
> maintained on a user by user and Web site by Web site basis."
>
> Slight digression:
> [Argh! Don't do that! Focus! Well, I know, but...]
> I note we're talking about "inhibiting content transformation" here,  
> not "allowing"... is it implied? If not, the sentence looks a bit  
> strange as I thought we were against the expression of blanket user  
> preferences to allow content transformation, but not against the  
> expression of blanket user preferences to inhibit content  
> transformation, so requiring that such a preference be maintained on  
> a Web site by Web site basis seems weird.
>
> I suggest that we leave the text as it stands (and address the above  
> digression).
>
>
> 3. Whether optimizing operations are still allowed, in other words  
> restructuring and recoding would be forbidden but not optimizing (we  
> may already have agreed on that at some point, I haven't had a close  
> look). Alternatively, we may use the notion of "proxies SHOULD  
> behave transparently when...".
>
>
> In short, a rough draft of the resulting guideline, that obviously  
> would need to go through the hands of an editor with delicate  
> fingers, could look like:
> Proxies SHOULD NOT restructure or recode the response if at least  
> one of the following affirmations is true:
>  - DOCTYPE is [foo]
>  - Content-Type is [bar]
>  - There's a <link rel="alternate" media="handheld" href="[same- 
> document-reference]" /> directive
> ... possibly completed with a "Proxies that operate in link-mode  
> [definition needed!] may still rewrite links in that case".
>
> HTH,
> Francois.
>
> [1] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-Example-Content-Types
> [2] http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-administrative-arrangements

David Storey

Chief Web Opener,
Product Manager Opera Dragonfly,
Consumer Product Manager Opera Core,
W3C Mobile Web Best Practices Working Group member

Consumer Product Management & Developer Relations
Opera Software ASA
Oslo, Norway

Mobile: +47 94 22 02 32
E-Mail: dstorey@opera.com
Blog: http://my.opera.com/dstorey

Received on Wednesday, 28 January 2009 14:44:46 UTC