Re: mandating respect of some heuristics

Sean Patterson wrote:
 >
 > -- A site is mobileOK does not guarantee that it will work
 > on any particular phone.

Fantastic! I can't believe my eyes. You really made my day, Sean./ /A 
native US speaker please help me: isn't this a textbook example of what 
americans call Chutzpah?

So, what we have here is a group that needed 4 years to come up with the 
definition of the MobileOK trustmark. You expect that very same group to 
ratify that MobileOK content can be transformed by a proxy simply 
because someone (worse, someone's software) may know better and make 
that content "even more optimised" for some definition of "more optimized"?

AFAIU, this is enough for TBL to send the Novarra membership cheque back 
and eject the company from MWI BPWG...

Luca


Sean Patterson wrote:
> See comments inline below.
>
> Sean
>
>   
>> -----Original Message-----
>> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] 
>> On Behalf Of Francois Daoust
>> Sent: Wednesday, January 28, 2009 8:01 AM
>> To: Mobile Web Best Practices Working Group WG
>> Subject: CT: mandating respect of some heuristics
>>
>>
>> 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.
>   
>> 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?
>>     
>
> I know of several deployments that operate in this mode (link-mode).
>
> Not allowing the rewriting of links of mobile pages puts the user in the
> position where clicking on a non-mobile link could cause "serious
> mis-operation" (loading a page that causes the browser to crash and
> maybe require a device reboot).  One of the goals of CT proxies is to
> protect users from these kinds of problems.  If the links are not
> rewritten, the CT proxy cannot do this.
>
> Other reasons to why it might be necessary to transform mobile content:
> --The site is mobile, but optimized for a higher-end phone than the user
> has.  The regular mobile site may not work well on the user's phone.
> --The mobile site may require pagination because it is too large for the
> user's phone.
> -- A site is mobileOK does not guarantee that it will work on any
> particular phone.
>
> I suppose these reasons would probably fall under the category of
> exceptions to the "SHOULD" clause.
>
>
>   
>> 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).
>>
>>     
>
> This is why I was confused about Jo's mention of site-by-site
> preferences for the restructured desktop experience.  The way I read
> section 4.2.2, it seems to mean that if a user specified that he wanted
> a restructured desktop experience, he could still specify that he wanted
> the mobile versions of certain sites.  (Of course if the user specified
> that he wanted a mobile experience, mobile sites would be presented as
> mobile with no transformation.)
>
> I don't remember deciding that we were against blanket user preferences
> for the restructured desktop experience.  We decided to treat blanket
> user preferences for desktop and mobile in the same way.  In fact, there
> was a resolution taken in Sophia that made this clear:
>
> RESOLUTION: if there is a blanket user preference asserted for any
> specific representation option and multiple representations are found to
> exist then the CT proxy server SHOULD inform the user of this fact and
> provide the user with an option to change to one of the alternative
> representations.
>
> I couldn't find any resolutions taken at a later date that restricted
> user preferences only to inhibiting CT.
>
> As far as transforming mobile content goes, I certainly see why there is
> reluctance to allow a lot of transformation to mobile sites.  However
> there are good reasons to allow the user to select whether mobile sites
> are transformed or not.
>
> 1)  The user may not want to leave the umbrella of the CT proxy for
> reasons mentioned above.
> 2)  The user may want a high end mobile page transformed into a version
> that works better on his phone.  The could be multiple reasons for
> this--the user's phone may not handle the CSS and/or JavaScript
> correctly, it may have a different screen size, it may not implement
> some(X)HTML feature(s) properly or at all, etc.  CT can help in these
> cases.
> 3)  The user may want toolbars in order to access various features
> provided by the CT proxy (history, bookmarks, etc.)  A link to the
> untransformed mobile page could also be put into the toolbars.
> 4)  Pagination of high end mobile pages may be required for lower end
> phones.
>
> I think the user would have sufficient browsing flexibility with the
> following configuration options:
>
> 1)  Allow each user to select either a "mobile mode" or a "desktop mode"
> for their browsing through a CT proxy.  Users would have to make a
> change to their browsing mode through some sort of configuration screen
> or dialog box.
>
> 1a) In mobile mode, the user would always see the mobile version of a
> site if there was one.  Only if there was no mobile version would a
> transformed version be presented.
>
> 1b) In desktop mode, the user would get the restructured desktop
> experience, unless the content provider prohibits it through the use of
> no-transform, etc.  There would be a requirement to include a link to
> the untransformed site if a site was transformed.
>
> 2) In both modes there would be the requirement that user could specify
> a preference to view individual sites in the other mode and this
> preference would be remembered by the CT proxy on a user by user and
> site by site basis.  This preference would remain until changed either
> by the user or the web site (e.g., if the web site changed its choice of
> representations (section 4.1.5.3)).
>
> I'm not saying we should spell this out exactly in the CT guidelines.  I
> think most of this is in the document already.  It just needs to be
> clarified.
>
>
>   
>> 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
>>     
>
>
>
>

Received on Tuesday, 3 February 2009 15:03:35 UTC