ISSUE-288 (includeNonMandatedHeuristics): non-normative heuristics

There are good reasons why to keep a list of heuristics in appendix E.

1) They provide concrete mechanisms to implement non-transformation guidelines,
as mentioned in section 4.2.9. This makes the document a practical one, where 
application providers know what to expect, and proxy operators what to do.

2) Many of these heuristics, such as the URL patterns one, are already deployed
in CT-proxies. Thus, they represent actual practice.

3) There is a concern that proxy operators will restrict their systems to follow
only those rules that are explicitly mentioned in a specification. Since section
4.2.9 mentions the heuristics that "proxies SHOULD apply", clearly listing them
in section E addresses that concern to some extent. The CT guidelines may evolve
to include, exclude or reclassify some rules as mandatory in the future anyway.

4) The distinction between mandatory and non mandatory rules arose from the fact
that the former heuristics were unambiguous and elementary (i.e. the simple 
presence of one specific pattern, such as DOCTYPE or MIME declarations, is enough
to identify content as mobile-specific), whereas others require a complementary 
indication to establish the characteristics of the content conclusively and the
BPWG has not endeavoured to define how to achieve this (e.g. some URL patterns).
This does not preclude a future refinement and reclassification of the heuristics
whenever experience leads to more precise rules.

5) Given the extent of legacy in the mobile Web, and the tendency for well
established techniques and practices to outlive hype cycles, we should not be
concerned about rules going "outdated quickly". Guidelines are meant to be based
on best practices, and such practices unavoidably derive mostly from legacy.

6) The list of rules is not extraordinarily long, considering the scope of the 
technologies and markets covered, and probably pales in comparison to all rules
and heuristics that reasonably effective CT-proxies must apply to convert content
in a sensible way.

Which all leads to the next issue: possible additional rules.

a) URL patterns.

Already listed under section E, they are used (not always consistently, but 
still) in a number of CT-proxies. They deserve to be preserved. This rule is of 
particular importance since it is one of the few explicit ones that is applicable
to requests instead of just responses.

b) MobileOptimized.

A Microsoft-specific meta-tag identifies Mobile-IE optimized content:
<meta name="MobileOptimized" content="NNN">
where NNN is a number of pixels. 
The argument advanced to reject this rule is that Mobile-IE has had scant success
in the mobile Web. After checking a bit for figures, I do not entirely share this
view -- the market share of Mobile-IE seems at least comparable to the one of the
iPhone (both of them being of course marginal in the overall mobile market). And
if we are to select rules on the basis of market success, then a mention of 
mobileOK, which does not formally exist right now and will not have measurable 
success for some time, is inadmissible as well.
MobileOptimized has a particular relevance, since it is a rare unambiguous rule 
that serves to distinguish HTML intended for (a specific class of) mobile devices
from generic desktop HTML.

c) Viewport.

As such, the presence of this meta-tag indicates that the content has been 
generated with WebKIT/Safari browsers in mind, but not necessarily that it is 
mobile-optimized. To assess this, one must inspect the additional attributes
associated to the viewport -- giving rise to a number of possible rules:
c.1) If the attribute content mentions "width=device-width" or 
"height=device-height", then the content has been designed for adaptability to
the target devices requesting it. Adaptations are unnecessary.
c.2) If the attribute content mentions "width=NNNN" or "height=NNNN", and NNNN
corresponds to the horizontal pixel length (respectively, the vertical pixel 
length) of display visible area of the device making the request, and either 
"initial-scale=1.0" or initial-scale is absent, then the content has been 
optimized for devices of the said width or height. Content adaptation is 
unnecessary.
c.3) If "user-scalable=no" is present, then the content is not to be rescaled
by the user -- a fortiori by a CT-proxy.
These are the rules I can think of -- more experienced developers with Safari
might come up with something else. Interestingly, the semantics of viewport and 
mobileoptimized intersect. In conclusion, it appears that rules about viewport 
correspond to the situation (4) described above. 


E.Casais

Received on Monday, 16 March 2009 09:39:14 UTC