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 15:17:04 UTC