Re: HTTP Gateway - by any other name?

I voluntarily skipped the HTTP references, first because I have the 
feeling we won't be finding an agreement in the obscure RFC, second 
because I have the naive feeling the most important point here is your 
last one!


Jo Rabin wrote:
[..]>
> So in general, I don't think that recasting this as "the proxy and the
> original user agent together should be considered as a distributed user
> agent" really clarifies anything, and I think is likely to be regarded
> politically as "we are looking for a loophole that demonstrates that we
> are entitled to do what we have been doing all along, and don't plan to
> change it irrespective of the inconvenience is it causing".
> 
> That's a very harsh way of putting it and I don't think that it's an
> accurate reflection, but I think we should be sensitive to possible
> perceptions of the outcome of this work.

I really think we must be clear on that:

- if we view our CT-proxy as an intermediary, then when our guidelines 
say "don't do CT", the CT-proxy MUST NOT do anything, and in particular 
must not insert other headers/footers/ads/whatever.
(with the exception of content filtering? why not? if that's against the 
carrier's policies, the carrier may reply with a Forbidden message...)

I don't want us to go into that direction for nothing. I mean, in 
practice, we need guidelines-compliant CT-proxies, and not a beautiful 
useless guidelines Recommendation (as a matter of fact, we wouldn't 
reach the Recommendation status in that case anyway).

I understand that's not exactly what the market currently is made of.
I would certainly be happy to go into that direction, provided others 
agree that is.


- if we view our CT-proxy as a user browser's extension, then indeed 
this gives us some more flexibility as to the actions the CT-proxy may 
do on behalf of "the user". There wouldn't be any clear definition of 
the CT-proxy beast. But we'd be closer to the actual beast.

Is that approach too naive?
Let's talk about that in next call, er... and that would be now...

Received on Tuesday, 19 February 2008 14:57:11 UTC