- From: Luca Passani <passani@eunet.no>
- Date: Tue, 24 Nov 2009 14:58:01 +0100
- To: Tom Hume <tom.hume@futureplatforms.com>
- CC: public-bpwg-comments@w3.org
You don't want to go around the houses again, but you keep deriving implications from my words which are not there. In the case of probing there is *nothing* that a site owner must do. In your case, the site owner must modify the way their site works. It is up to a proxy to recognize that a URL is pointing to a JAD file and probe should not take place. Luca Tom Hume wrote: > Not that I'm going to go around the houses with you on this one again, > Luca... > > My point is, you're applying a double standard: in the case of probing > you're expecting site authors to account for it (which as you say, > they can do easily). In other cases (looking at different HTTP headers > or adding a no-transform directive) you're saying it's unreasonable > for them to be expected to make changes. > > I think either position could be consistent by itself, but together > they're contradictory. > > 2009/11/24 Luca Passani <passani@eunet.no <mailto:passani@eunet.no>> > > Tom Hume wrote: > > I agree, it can be done safely and easily - though many to > date haven't done so; in much the same way that site authors > can reconstruct original headers by looking at > X-Device-User-Agent, and prevent transformation by adding a > "no-transform" header - safely and easily. > > > I disagree. The onus of safeguarding mobile content sits squarely > on the shoulder of transcoders and operators who deploy them. > > It is not fair (nor reasonable) to force everyone to change the > way their web applications work to avoid falling victim of the > greed of some. > > Luca > > > > 2009/11/24 Luca Passani <passani@eunet.no > <mailto:passani@eunet.no> <mailto:passani@eunet.no > <mailto:passani@eunet.no>>> > > > 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> > <mailto:passani@eunet.no <mailto:passani@eunet.no>> > <mailto:passani@eunet.no <mailto:passani@eunet.no> > > <mailto: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> > <mailto:Tom.Hume@futureplatforms.com > <mailto:Tom.Hume@futureplatforms.com>> > <mailto:Tom.Hume@futureplatforms.com > <mailto:Tom.Hume@futureplatforms.com> > <mailto:Tom.Hume@futureplatforms.com > <mailto:Tom.Hume@futureplatforms.com>>> play: tomhume.org > <http://tomhume.org> > <http://tomhume.org> <http://tomhume.org> > > > > > > > > > -- > Future Platforms: hungry and foolish since 2000 > work: Tom.Hume@futureplatforms.com > <mailto:Tom.Hume@futureplatforms.com> > <mailto:Tom.Hume@futureplatforms.com > <mailto:Tom.Hume@futureplatforms.com>> play: tomhume.org > <http://tomhume.org> <http://tomhume.org> > > > > > > > -- > 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:58:44 UTC