RE: ACTION-902 Summarise and prepare proposed resolutions on HTTPS link rewriting.

Hi Luca,

To be clear I'm talking about the need to make the transcoder's
"virtual-browser" the origin domain only when it has been established
beyond reasonable doubt that the content (requested for the mobile's
User-Agent) isn't suitable for this User-Agent and that it needs
adaptation. I totally agree that changing origin domain is adaptation
and therefore MUST NOT be done to content that's already
mobile-friendly.

Thanks,

Rob

-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Luca Passani
Sent: Mon 16 March 2009 13:58
To: Public MWBP
Subject: Re: ACTION-902 Summarise and prepare proposed resolutions on
HTTPS link rewriting.

Roberts,

I think that, from an engineering perspective, your comments make sense.

On a more general level, when the big picture of the problem is 
considered, they do not. Here is my view (with my Manifesto editor hat):

- transcoder vendors have shown how skillful they are in driving a train

through any loophole they find in whatever specs that serves their 
purpose. For this reason, the only sensible stance CTG should take is to

force transcoders to err on the side of NOT reformatting whenever in the

presence of content which might already be fit for mobile (Novarra has 
publicly declared multiple times their intention to transcode 
already-mobile-optimised content too).

I think the rules should still say MUST NOT. Actual implementations may 
take the freedom to override those rules when they feel their superior 
technology has made it clear that it's no a mobile site they are dealing

with. "Should not" is too weak.

Alternatively, you can re-think CTG and take an approach like the one in

the Manifesto. Do not spoof the UA or any other HTTP header in any way. 
If the response is full-web, and not fit for mobile beyond reasonable 
doubt, a transcoder can re-issue a spoofed request to get a clean 
web-only response and take off with transcoding from there. At that 
point, a transcoder can apply all of its dirty tricks to achieve 
best-effort transcoding, without interfering with the work of those who 
have mobile content in place (and without caring too much about these 
heuristics).

This idea was discarded by CTWG because of the fact that multiple GETs 
may not yeld the same result, but this argument is totally bogus when 
applied to a technology which is doing best-effort adaptation in the 
first place.

Luca

Robert Finean ha scritto:
> Origin domain is changed during adaptation for good reasons and it
does
> seem absurd to give network operators a MUST NOT for this but
everybody
> else an out-of-scope. Just to be 100% clear this is changing origin
> domain solely to adapt long-tail content that won't work on the phone
> otherwise.
>
> All use-cases can't work with this MUST NOT. For example:
>
>  - A good number of pre-2006 handsets truncate URIs at 256 chars. Many
> long-tail websites use URIs longer than this and appending even more
> information using specific query-string params makes matters worse
> still.
>
>  - Any frameset MUST be flattened for XHTML/MP phones: the frames will
> have their URIs disappear completely from the phone's perspective.
>
>  - Tokenisation of URIs as a compression technique results in
> much-improved user-experience on phones with limited heap RAM,
including
> the most popular phones on the planet.
>
>
> In summary, I'm still unclear what the root concern is and I doubt if
> it's feasible to make all use-cases work with this restriction. Hence
I
> doubt if you would get any compliant implementations of the candidate
> rec.
>
> Thanks,
>
> Rob
>
> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org] 
> Sent: Thu 12 March 2009 15:13
> To: Robert Finean
> Cc: Jo Rabin; Public MWBP
> Subject: Re: ACTION-902 Summarise and prepare proposed resolutions on
> HTTPS link rewriting.
>
> Robert Finean wrote:
>   
>>>> b. PROPOSED RESOLUTION: In-network proxies MUST NOT rewrite links 
>>>> without explicit prior agreement from the Content Provider
>>>>         
>> -1 because explicit prior agreement from 50M long-tail Content
>>     
> Providers
>   
>> won't happen. Link rewriting (HTTP and/or HTTPS) is part of
adaptation
>> because:
>>  - URIs must be invented to represent browsing actions within a
single
>> Content-Provider's URI (eg view a different sub-page; trigger a
>> javascript event; move from one part of a form to another where a
form
>> is split across sub-pages)
>>  - Tokenising URIs is a very effective data-compression trick for
>> adapted content that dramatically improves end-user usability
>>
>> There are security implications that need to be laid out and
>>     
> addressed.
>   
>> Those security implications are the vital issue here, not link
>> rewriting. Even flattening a frameset into one page for display on an
>> XHTML/MP phone can raise these security questions so link rewriting
>> isn't the crux of the matter.
>>     
>
> The crux of the problem is indeed not links rewriting per se, it's the

> change of origin.
>
> The proposed resolution could rather read:
>
> PROPOSED RESOLUTION: In-network proxies MUST NOT change links origin 
> without explicit prior agreement from the Content Provider (where 
> "origin" is defined as the domain name, the scheme and the TCP port of

> the link)
>
> Can all use cases be done without changing the origin? I think most
can,
>
> for example using specific query string parameters in the request that

> the CT-proxy reacts to. Is it a clean solution though? I'm not sure. 
> Besides, I don't think it covers the frameset case, but then
flattening 
> frames with different origins is probably not a good idea.
>
> I understand tokenisation of URIs decreases size. That's not enough of
a
>
> use case to allow a change of origin, IMHO.
>
> Francois.

Received on Monday, 16 March 2009 14:58:51 UTC