Re: Feedback on content transformation guidelines ( LC-2066 LC-2067 LC-2068 LC-2069 LC-2070 LC-2071 LC-2073 LC-2072 LC-2074 LC-2075 LC-2076 LC-2077 LC-2078 LC-2079 LC-2080 LC-2081 LC-2082 LC-2083 LC-2084)

I agree that there may be trouble if one downloads a JAD file multiple 
times.

I disagree that there may be trouble if a proxy hits:

http://www.acmilan.com/

in order to check whether a mobile experience is being offered or not. 
The fact that there may be (easily identifiable) cases where multiple 
GETs may change the status of the site, does not mean that probing the 
site cannot be performed safely for all the parties involved.

Luca

Tom Hume wrote:
> I've seen mobile content services where repeat-GETs cause problems. 
> For instance:
>
> 1. Download services that limit the number of downloads (GETs) to 
> protect content assets;
>
> 2. Download services which trigger the build of an asset server-side 
> (e.g. JAR file for MIDlet) based on the User-Agent of the first hit;
>
> 3. Statistical analysis of server logs where double-hits can affect 
> page views, etc.
>
> All these are IMHO common techniques that I've seen more than one 
> provider of mobile content use.
>
> 2009/11/24 Luca Passani <passani@eunet.no <mailto:passani@eunet.no>>
>
>
>     Hi Mark, I am not part of BPWG, but I followed the work of the WG
>     very closely and I think I can provide some of the answers  to
>     your questions (Disclosure: I am the author of the Manifesto for
>     Responsible Reformatting,
>
>     http://wurfl.sourceforge.net/manifesto/
>
>     The Manifesto addressed the same issues CTG that is addressing
>     with overwhelming support from the community, operators and a few
>     key transcoder vendors too)
>
>     comments (and answers) in-line
>
>
>     Mark Nottingham wrote:
>
>
>         * 4.1.5.1 "The theoretical idempotency of GET requests is not
>         always respected by servers. In order, as far as possible, to
>         avoid misoperation of such content, proxies should avoid
>         issuing duplicate requests and specifically should not issue
>         duplicate requests for comparison purposes."
>         Existing proxies can and do already retry GETs; I'm not sure
>         who you're trying to protect here.  
>
>     They are protecting Novarra Inc. ( http://www.novarra.com/ ). "GET
>     idempotency" is an excuse to kill a reasonable approach to test
>     whether a website has a mobile experience ready for visitors or
>     not. Proxies could make a request with unaltered HTTP headers,
>     ascertain that there is no mobile experience ready for that device
>     and move on to spoof the UA string for that site from that moment
>     on (if there is a mobile experience in place, then their
>     intervention is not needed and in fact totally undesirable).
>
>     The problem with this approach (for Novarra) is that this would
>     not allow their proxy to fool the website and extort full-web
>     content also in the presence of a mobile experience.
>
>     Please also observe that "probing" is what some commercial proxies
>     do (and performance is not an issues, because nothing prevents
>     that a proxy caches the result of recent "probs" for a few hours).
>
>
>         My concern is that Recommending this document will cause more
>         harm than good to the Web overall (even if it does represent a
>         consensus of sort among a more limited community).
>
>
>     I of course agree. Just wanted to observe how the "limited
>     community" is in fact "very limited", since it only accounts for
>     the needs of some transcoder vendors and Vodafone. The
>     overwhelming majority of the mobile ecosystem hates transcoders
>     and support for the aforementioned Manifesto proves this.
>
>     Thank you
>
>     Luca
>
>
>
>
>
>
> -- 
> Future Platforms: hungry and foolish since 2000
> work: Tom.Hume@futureplatforms.com 
> <mailto:Tom.Hume@futureplatforms.com> play: tomhume.org 
> <http://tomhume.org>
>
>

Received on Tuesday, 24 November 2009 13:39:05 UTC