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

Jo,
For the purposes of the CT requirements, what you are describing as a
"Transparent Proxy" is irrelevant. In fact, such a limited-purpose proxy
has little value to network service providers (except perhaps in
enterprise environments), and is unlikely to factor into their
deployments (it certainly doesn't into ours). Proxies usually must add
some other value to justify the considerable expense of
deployment/operation.

I suggest we focus on the cases where the proxy is assumed to add
further value and will as a result, modify the request/response except
as defined in the CT requirements.

Further, how you describe the "gateway" is not consistent with typical
deployments of gateways:
a) A "gateway" typically means that there is some protocol translation
going on, not just content transformation. Thus WAP1 requires a
"gateway", while WAP2 only requires a "proxy". A proxy typically does
not change the protocol used in serving user-agent requests.
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.

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.

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 Saturday, 2 February 2008 23:08:24 UTC