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

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 08:23:02 UTC