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 13:58:34 UTC