RE: CT: mandating respect of some heuristics

I have a couple of observations - inline.

> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
On
> Behalf Of Eduardo Casais
> Sent: 02 February 2009 15:49
> To: public-bpwg@w3.org
> Subject: 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.

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.

> 
> 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'm inclined to think that for this reason, a transformation that
consists only of URI rewriting is not really transformation.

> 
> > 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 21:54:16 UTC