RE: mandating respect of some heuristics

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 06:04:56 UTC