Re: mandating respect of some heuristics

Hi Sean,
See other comments below.

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

OK. Personally, I'm fine with adding URI rewriting as an exception for 
CT proxies that operate in link-mode.


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

I don't think it falls under the category of exceptions to the "SHOULD" 
clause. The gist of the guideline is really to protect mobile content, 
no matter if it's not entirely appropriate, IMO.

Many content providers that publish mobile content spent time addressing 
the user mobile experience. They may well have a precise knowledge of 
the user agent's limitations and may have deliberately decided to serve 
e.g. slightly too big a page because they felt it was important and 
because they decided it had a reasonable cost in the end combined with 
e.g. long-lasting caching directives. In such cases, the CT proxy should 
not be in a position to decide otherwise.

I understand that many content providers simply go "iPhone", and do not 
truly go "mobile". These content providers could benefit from CT, but...

... for the time being, there is no way for content providers to 
advertise the fact that a given representations is specifically tailored 
for the user's precise device or only for a bucket of high-end devices. 
It's mobile (or "handheld"), period. I hope we can find ways to 
advertise this in the future (sounds like a good job for super-POWDER, 
but we'll see what the future brings). In the meantime, this type of 
content should be protected.

[Side note: actually, an iPhone version could well fall out of the scope 
of the guideline and still be opened to transformation, because we're 
really talking about *explicit* mobile flags, and an iPhone specific 
page typically:
  1. uses XHTML 1.0 Strict or HTML 4.01
  2. is served as application/xhtml+xml or text/html
  3. could contain a <link rel="alternate" media="only screen and 
(max-device-width:480px)" href="" /> because that's usually how an 
iPhone is detected to have a dedicated CSS style sheet. I don't think 
anyone uses this kind of link element today, but the point is, having a 
media="handheld" there would seem awkward since the iPhone does not 
present itself as a "handheld" anyway.
None of these points would trigger the guideline.]

Pagination of extra-long pages could be a valid exception to the rule 
e.g. if content size goes beyond the limits of the device, but not as a 
generic "I decided pages need to be under 20Kb" rule.

Francois


> 
> 
>> 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 10:00:27 UTC