Re: CT: mandating respect of some heuristics

> There are no other identified explicit mobile flags.

There actually is one: the Microsoft-specific meta-tag
"MobileOptimized" intended to identify Mobile-IE optimized
content.

<meta name="MobileOptimized" content="nnn">

where nnn is a number of pixels.


> The proposal could be to complete the guideline with 
> an explicit exception for links rewriting for proxies 
> that operate in that mode.

Now, I shall restate my position:

a) As a matter of principle, mobile-specific responses 
should not, and need not be altered -- whatever form of
proxy is used.

b) If transformation of desktop-specific content is 
expected, then this may have a consequence on mobile
pages as well, depending on the proxy implementation
(most notably: URI rewriting).

c) Since mobile content should not be altered, the operator
of a CT-proxy must have a good reason to let it perform
URI rewriting. If the CT-proxy is an opt-in, out-of-band
proxy (such as GWT, Mowser, etc), then it is fairly 
evident why (it is impossible for the CT-proxy to work
otherwise).
If the operator is a telecom operator, then all HTTP 
traffic is gated through an operator-controlled proxy
anyway, and the reason to use an URI-rewriting dependent 
implementation is unclear and must be substantiated.


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

This is actually perspicacious. Section 4.2.2 must be rewritten
to enforce coherence with 4.1.5.3, where the converse approach is
specified: "Proxies may offer users an option to choose to view a 
restructured experience even when a Web site offers a choice of user 
experience. If a user has made such a choice [...]".

I hope that expressing a preference in the form * to mean "all
sites" is also covered by the statement in 4.2.2.


> Proxies SHOULD NOT restructure or recode the response if at 
> least one of the following affirmations is true:

We decided to renounce giving a formal definition of "restructure" 
and "recode", which makes such a sentence difficult to test. As a 
rule, the response should not be altered (except as to fulfil 
RFC2616 etc...)


> possibly completed with a "Proxies that operate in link-mode 
> [definition needed!] may still rewrite links in that case".

This is an implementation issue. Do we want to start defining
how a specific implementation work for a very specific deployment
and transformation environment? As stated above, if there is no
other way to make things work than by rewriting URI just to make
sure desktop content gets transformed when so desired, then the
SHOULD/SHOULD NOT without further qualifications seems enough
to me.


E.Casais

Received on Monday, 2 February 2009 15:49:20 UTC