W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > June 2008

Re: ACTION-678: Raise and issue on the distinction between a CT proxy and (say) Opera Mini

From: Jo Rabin <jrabin@mtld.mobi>
Date: Wed, 11 Jun 2008 11:32:11 +0100
Message-ID: <484FA9AB.70107@mtld.mobi>
To: Francois Daoust <fd@w3.org>
CC: Sean Patterson <SPatterson@Novarra.com>, public-bpwg-ct <public-bpwg-ct@w3.org>

On the whole I see the logic of this argument. However, in the interest 
of improving the lot of the CP there are a few things that it would be 
useful to note - e.g. that the combined proxy/client can use the 
no-transform directive to stop upstream components doing transformation.

Also it would be useful for the device type / model and the original IP 
address to be recorded - the issue that is frequently noted with the 
Opera solution is that it causes all traffic to appear to come from Norway.

So in summary I think the document is applicable in parts to such 
solutions and we should note that. Probably we should note which parts 
as an appendix.

Jo

On 11/06/2008 09:22, Francois Daoust wrote:
> 
> As said during the call yesterday, I second your thoughts on this.
> We haven't resolved anything yesterday to let other participants some 
> time to react.
> 
> I propose the following for resolution (or further discussion) next week:
> 
> PROPOSED RESOLUTION: unless the proxy is a non-transparent HTTP proxy, a 
> proprietary client/proxy content adaptation solution is a black box that 
> behaves like a regular User Agent as far as content providers are 
> concerned. As such, it is out of scope of our guidelines that only 
> address CT proxies.
> 
> (+1 to this)
> 
> and a QUESTION: do we append a note to explain this in the guidelines?
> 
> (-1 to this, as I think the definition of non-transparent proxy is enough)
> 
> Francois.
> 
> 
> Sean Patterson wrote:
>> At the F2F meeting in Korea, I was given the action of getting some 
>> discussion started on how the CT guidelines should handle CT solutions 
>> that consist of both a CT proxy and a proprietary client.  I've been 
>> derelict on doing anything about this, so I'd like to try and make 
>> amends by getting something started now.
>>
>> At the Korea F2F meeting, there was some discussion about what to do 
>> about CT solutions that contain both a CT proxy and an associated, 
>> proprietary client (Novarra has been doing this on various platforms 
>> for years; Opera Mini is probably the best known example to the 
>> general public).  No real resolution was reached and it was decided 
>> that we should try to get some discussion going on the CT mailing list 
>> on this topic.
>>
>> I guess the question is:  should CT client/proxy solutions be required 
>> to follow the same CT guidelines as CT proxy solutions?  The CT 
>> guidelines as they currently exist only mention proxy solutions; 
>> client/proxy solutions are not mentioned.
>>
>> My opinion is that client/proxy solutions should be treated as mobile 
>> browsers that just happen to be distributed across a client device and 
>> server machine; i.e., the client and proxy are part of a browsing 
>> solution in which neither is designed to work without the other, so 
>> they must be treated as one entity.  I would argue that as far as 
>> content providers are concerned, this entity is more like a browser 
>> than a proxy.  Content providers would see the client/proxy 
>> combination as just another mobile browser since they would never see 
>> the client by itself without the proxy.  The client/proxy solution 
>> will have its own HTTP request header values (including User-Agent) 
>> and any special mobile content would need to be designed for the 
>> entire client/proxy combination, not just the client.
>>
>> Currently, users tend to install the client for these client/proxy 
>> solutions themselves in addition to whatever native browser was 
>> pre-installed on the device.  However, I think this is a side issue 
>> and not really relevant as to whether these solutions need to follow 
>> the CT guidelines.  A mobile operator could easily install a 
>> client/proxy solution in their network--including the pre-installation 
>> of the client on mobile devices that it resells.  (In fact, this has 
>> been done.)
>>
>> It appears to me that the Mobile Web Best Practices Guidelines and the 
>> MobileOK Basic Tests are the most relevant BPWG documents for 
>> client/proxy solutions.  My opinion is that client/proxy solutions 
>> should not be required to follow the CT Guidelines.
>>
>> Sean
>>
> 
Received on Wednesday, 11 June 2008 10:32:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:29 UTC