RE: [ACTION-603] Conversation with Yves, our HTTP expert, about CT and Cache-Control extensions

Francois,
When I spoke of gateway behavior, I was thinking of protocol translation, e.g. WAP1 to HTTP. But Rob pointed out that these functions are also "gateway" related:
- taking a large page and breaking it into smaller pieces, and serving the pieces from URI's hosted on the gateway
- adapting Javascript applications for devices that don't support Javascript, by again serving the page locally and emulating the Javascript functions through markup
- rewriting HTTPS links as gateway-local URI's to enable CT on the content when retrieved by the browser

I think those use cases are more valuable to consider than the general implications of WAP1 gateways re CT. If the CT guidelines need to mention WAP1 gateways, I recommend that it be a footnote on legacy services only, as it's a correct (and probably unchangeable anyway) behavior that WAP1 gateways ignore the no-transform directive for certain functions, e.g. lossless compression. WML to WMLC encoding (or "compilation") should be lossless, and is essential anyway for most devices that support WMLC, since they usually don't support text WML. 

Further, whether a gateway should take HTML (in the presence of a no-transform directive) and convert it to WML/WMLC if the browser doesn't support HTML, is another question; probably no, but again we're unlikely to see any changes in gateways that do act this way.

Best regards,
Bryan Sullivan
-----Original Message-----
From: Francois Daoust [mailto:fd@w3.org] 
Sent: Monday, February 04, 2008 4:51 AM
To: Sullivan, Bryan
Cc: public-bpwg-ct
Subject: Re: [ACTION-603] Conversation with Yves, our HTTP expert, about CT and Cache-Control extensions

Hi Bryan,

Sullivan, Bryan wrote:
[...]
> a) Gateways do not act as if they are the origin server (to do so it 
> would have to rewrite all URI's). They just act as a proxy, i.e. the 
> user-agent sends requests to the gateway as proxy, rather than doing 
> DNS lookup on the hostname in the URI and sending the HTTP request to 
> the IP address of the hostname.

That also was what I thought before mentioning the term "gateway". The answer (the HTTP-spirit-oriented answer, that is) seems to be that a gateway can be an "intercepting" gateway: the user agent sends requests to the origin server, and the gateway intercepts the request as if it were the origin server, processes it as it likes (re-issuing the request to the original origin server as necessary) and returns a response.

Thus, a WAP1 gateway really is a "gateway" as defined in the RFC2616, and we could call our CT-proxy a CT-gateway if we like.

But using the term "gateway" surely is misleading in the context of a mobile world already full of them. Actors in the field will think of "gateways" as WAP gateways.

I personally would prefer we stick to CT-proxy, but my point is: if the CT-proxy may override the User-Agent string, then when we talk to HTTP folks or reference the HTTP RFC2616, we should call it a CT-gateway, or make it clear we understand it fits more with the definition of a gateway but still prefer to call it a CT-proxy, or we'll get replies such as:
"this guideline MUST be removed, because a proxy MUST NOT override the user-agent string" (although, as stated before, that's not truly written
anywhere)



> 
> Whether a CT proxy is a simple proxy or adds gateway functionality may 
> be of interest in the CT requirements, but is a secondary issue. We 
> can make statements re the expected/necessary function of a WAP1 
> gateway re content transformation, but the "value-add" of a WAP1 
> gateway re CT is the same as that of CT proxies in general. Further, 
> as I've mentioned, it's unlikely that WAP1 gateway vendors will modify 
> their products fot the CT requirement (or that network operators, e.g. 
> us, would ask for or deploy such enhancements). WAP1 is really nearly 
> gone, and will certainly be for any significant degree (at least for 
> AT&T) by the time that WAP1 gateway producs could incorporate the CT 
> requirements. If you want to consider the CT requirements in the WAP1 
> delivery context, I suggest that you consider the "corner case" of a 
> CT proxy being on the internet side of WAP1 gateways only.

That's the exact reason why using the term "gateway" is confusing... It wasn't my intention to even mention what WAP1 gateways should do regarding content transformation. I second you on that: it's nearly gone, not worth spending time on it, unless someone thinks that's necessary.


François.





> 
> Best regards,
> Bryan Sullivan | AT&T | Service Standards -----Original Message-----
> From: public-bpwg-ct-request@w3.org
> [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Robert Finean
> Sent: Saturday, February 02, 2008 10:14 AM
> To: Jo Rabin
> Cc: public-bpwg-ct
> Subject: RE: [ACTION-603] Conversation with Yves, our HTTP expert, 
> about CT and Cache-Control extensions
> 
> 
> True. And that's from the HTTP/1.1 RFC so equally authoritative (I 
> fell into a common misnomer). Do we have 3 types of CT-node then? ie:
> 
>  1. Transparent Proxy - does not modify the request or response beyond 
> what is required for proxy authentication and identification.
>  2. Non-transparent Proxy - modifies the request or response in order 
> to provide some added service to the user agent but a proxy MUST NOT 
> override the User-Agent header (it MAY complete the User-Agent header).
>  3. Non-transparent Gateway - unlike a proxy, a gateway receives 
> requests as if it were the origin server for the requested resource. A 
> gateway re-issues the HTTP request and is thus allowed to set HTTP 
> headers to whatever it wants.
> 
> A CT-node like OpenWeb can operate in any of the three modes depending 
> on the destination content. Eg if it's already mobile-friendly content 
> the CT-node would operate in Transparent Proxy mode. If it's a single 
> object that needs transformation (eg .wmv to .3gp) this can be done in 
> Non-transparent Proxy mode. If it's desktop-style content full of 
> Javascript then the CT-node would turn the whole browsing session into 
> Non-transparent Gateway mode, where it can make up its own URLs to 
> handle Javascript events and sub-pages.
> 
> 
> Robert
> 
> -----Original Message-----
> From: Jo Rabin [mailto:jrabin@mtld.mobi]
> Sent: Sat 02 February 2008 15:17
> To: Robert Finean; public-bpwg-ct
> Subject: RE: [ACTION-603] Conversation with Yves, our HTTP expert, 
> about CT and Cache-Control extensions
> 
> Well, thanks for the clarification, but I can't see how the following, 
> under 1.3 Terminology, can be interpreted that way:
> 
>       A "transparent proxy" is a proxy that does not modify the 
> request or
>       response beyond what is required for proxy authentication and
>       identification. A "non-transparent proxy" is a proxy that modifies
>       the request or response in order to provide some added service to
>       the user agent, such as group annotation services, media type
>       transformation, protocol reduction, or anonymity filtering. Except
>       where either transparent or non-transparent behavior is explicitly
>       stated, the HTTP proxy requirements apply to both types of
>       proxies.
> 
> 
> Jo
> 
>> -----Original Message-----
>> From: Robert Finean [mailto:Rob.Finean@openwave.com]
>> Sent: 02 February 2008 13:16
>> To: Jo Rabin; public-bpwg-ct
>> Subject: RE: [ACTION-603] Conversation with Yves, our HTTP expert,
> about
>> CT and Cache-Control extensions
>>
>> A non-transparent HTTP proxy is one that is explicitly configured in
> the
>> client; HTTP Proxy Transparency is all about layer 4 and says nothing 
>> about layer 7. This Gateway vs Proxy distinction is about layer 7,
> where
>> content is transformed, and therefore is a very useful definition for 
>> us.
>>
>> Thanks,
>>
>> Robert
>>
>>
>> -----Original Message-----
>> From: public-bpwg-ct-request@w3.org
>> [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Jo Rabin
>> Sent: Fri 01 February 2008 17:27
>> To: fd@w3.org
>> Cc: public-bpwg-ct
>> Subject: RE: [ACTION-603] Conversation with Yves, our HTTP expert,
> about
>> CT and Cache-Control extensions
>>
>>
>>
>>
>>>> I wonder whether we do indeed want a Gateway? I'm wondering if
> this
>> is
>>>> merely a choice of words issue or whether there is a deeper 
>>>> significance? My view is that content should be transformed "more
> in
>>>> sorrow than in anger", whereas saying it is a Gateway suggests
> that
>>>> transformation is a matter of routine.
>>> Actually, I view it more like saying "beware, CT ain't no routine!":
>> if
>>> you do transformation, you are indeed being aggressive, and as such,
> 
>>> you're not merely a (non-transparent) proxy anymore. Where "not
> merely
>> a
>>> proxy anymore" is "a gateway". That may be too HTTP-centric though
> and
>>> we may decide to shrug at it and keep on using the term proxy...
>> I'm just wonder what the HTTP notion of a non-transparent proxy is, 
>> if
> 
>> it isn't a transforming proxy. Various sections spell out that 
>> transformation is understood to be what a "non transparent" proxy is 
>> expected to be. I obviously don't know enough about the "spirit" to
> have
>> this clear in my mind so it would be an advantage if we could get 
>> someone who is knowledgeable to explain this, apparently crucial,
> point
>> in detail.
>>
>>>> I can't say that I infer that the User Agent MUST NOT be changed
>> from
>>>> the referenced text. In the preceding section there is an explicit
> 
>>>> prohibition on changing the Server value. There is no such
> explicit
>>>> prohibition noted wrt the User Agent.
>>> [...]
>>>
>>> It isn't written anywhere for sure. That's where the "spirit" of
> HTTP
>>> comes in... We may want to ask other HTTP folks about it to check 
>>> whether they all agree on the matter, but I think Yves' view fairly 
>>> represents theirs. The header is not included in the list of headers
> 
>>> that MUST NOT change, in part because it MAY change (such as the 
>>> Openwave gateway that added (still does?) a UP.Link/x.y part to the 
>>> User-Agent). But the definition of the User-Agent makes it clear it
>> must
>>> contain something that identifies the user agent making the request.
>> If
>>> we do define our proxy as a gateway though, the violation of the 
>>> "spirit" disappears, as from the server, the gateway would be viewed
>> as
>>> the user agent making the request.
>>>
>>> Again, that may be playing with words, but I guess my point is we
>> should
>>> be consistent with the HTTP RFC since it's the base of our
> guidelines.
>> Sure, but it seems that we both have to be consistent with the words 
>> that are actually written - i.e. the RFC - and "the spirit" which is 
>> not. I suppose that I could be accused of being a fundamentalist if I 
>> said "If it's not written it doesn't exist", but I am at a loss as to 
>> how one gets the "spirit".
>>
>>> Maybe we could propose that they actually use a DDR to identify
>> desktops
>>> and serve the handheld version by default? (So what, isn't Mobile
> Web
>>> supposed to rule over the Web?)
>> I see you have got the hang of it already! One Web to Rule them All.
>>
>>> I propose we talk about it in next call.
>>>
>>>
>>>> I share Yves's view on rewriting HTTPS URIs however, that
>> immediately
>>>> knocks on the head the idea of mobile access to HTTP URIs that are
>> not
>>>> mobile friendly - and probably therefore a significant number of 
>>>> useful mobile services.
>>> I understand it limits the possibilities in terms of useful mobile 
>>> services, and I also understand it's already being done by some
>> content
>>> transformation proxies. But the banking example is one that will be 
>>> difficult to put aside when we try to convince external non-mobile 
>>> people that this is amazingly needed.
>> Better to get the banking people to write mobile interfaces, by far.
> But
>> how will they tell the proxies not to transform ...
>>
>> See you on the call.
>>
>> Jo
>>
> 
> 
> 
>

Received on Monday, 4 February 2008 15:00:42 UTC