Re: mandating respect of some heuristics

> If I stick a Content-Type: application/vnd.wap.xhtml+xml header on my
> content, this doesn't automatically confer the content with special
> powers. In particular it doesn't mean that I have correctly construed a
> response for this specific device. And incidentally, it doesn't mean
> that I am not being malicious.

The relation is between application providers and end-users; CT-proxies are not
the customers of application providers. It is up to CT-proxies to be very 
careful with applications -- it is not up to application providers to prove
that they have built a valid mobile application.

>From this perspective, all unambiguous elements marking an application as
mobile-specific imply that CT-proxies must demonstrate they have a very good
case to alter it.


> I'm inclined to think that for this reason, a transformation that
> consists only of URI rewriting is not really transformation.

All URI-rewriting of the kind http://www.proxy.com/doit?www.app.ch/path/page
or http://www.proxy.com/doit/www/app/ch/path/page increase the size of the URI
within the mobile page. If the resulting page exceeds the limit for the target
device, then the consequence is pagination -- a substantial change in the 
control flow and usability of the application. Besides, the semantics of the 
original link are modified: it is no longer a link to a site, but a redirection
to a site.

If on the other hand the URI is replaced with some hash (like tinyurl), then 
the semantics are further modified -- it is a link to a procedure that maps a
hash to a site. Not only is the link less "meaningful", there is little 
guarantee that it is permanent (when bookmarking), or that it is accessible to
users who are not the operator's customers (sending the link elsewhere will 
not work). 

In both cases, since the actual URI accessed by the end-users are modified, 
other information, notably referer, must be adjusted (i.e. spoofed) to maintain
some consistency with the behaviour of the application server.

URI rewriting, an apparently trivial operation, thus entails changes in link
semantics, restructuring of the content, and ripple effects on other parts of
the HTTP flow. It is definitely a transformation, and not a benign one.


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

If the user has decided not to allow restructuring, then that is the risk and
the expected result. There is no reason to override the user's decision. I also
have had problems in the desktop Web with sites optimized or loaded with 
plugins that made some browsers bomb.


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

How do you know for which kind of device the application has been implemented?
Why does it make sense to make site optimized for a high-end phone, making use
e.g. of compiled application download, streams or synchronization features, 
available to a lower end one? How can you ensure it will work at all?

> --The mobile site may require pagination because it is too large for the
> user's phone.

If the pagination breaks the flow of control, then the result may as well be
not usable.

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

It supposedly guarantees that it should work on a large range of devices with
some specific minimal configuration. 

> I suppose these reasons would probably fall under the category of
> exceptions to the "SHOULD" clause.

I am not ready to provide general blanket exceptions in the CT-guidelines. The
discussion on links rewriting shows that if we want to specify exceptions, then
we have to specify so much context and conditions that we end up specifying
an implementation -- I do not want to do this. The SHOULD/SHOULD NOT leaves a
possibility for well-founded modifications to mobile content, on a case-by-case
basis, and open-ended as to implementations and technology.

> [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:

That is why there are heuristics in the _request_ side regarding URI, so that
patterns of the form iphone.* should be considered as pointing to an iphone
optimized site (which it probably is). From that perspective, the CT-document
is quite appropriate.


E.Casais

Received on Tuesday, 3 February 2009 14:18:07 UTC