RE: no-transform & Warning

Again, for me this comes to the semantic overload: CC is an explicit
Cache Control directive. As such it has nothing to do with OPES
gateway behavior. I agree that it may me useful to have a
directive(s) for explicit per-message control of OPES gateway, but
we should not try to use existing HTTP headers - this is a
semantics overload (in the sense of C++ class member operators
overload).

For this particular operation (non-transform) our discussion looks
like pure academic - I am not aware of wide (or in fact any) use of
this header or 214 response. This leads to the temptation to use the
existing directive instead of introducing a new one. But a)this is
not a good practice (IMHO);
b) consider future development. If I understand correctly here we are
not looking at callout protocol itself - this kind of directive should
be interpreted by the application protocol gateway, not callout server.
We may need other directives to control gateway behavior. Adding
additional fields to Cache-Control header does not look a good idea
for extensions. For OPES gateway control we need an additional header
(x-opes-control). Use of CC just for one purpose creates a "legacy
branch" in a brand new protocol.

To summarize the issues:

1. Problems related to the application protocol interaction with
gateways should be considered separately from callout protocol
used by gateway to tunnel the request to the callout server.

2. We may need a set of directives to control a gateway included
in the application protocol. These directives are especially
useful to control per-message gateway behavior.

3. As a separate issue - while transport features of callout protocol
may be application-protocol agnostic, semantics of callout protocol and
server may need application protocol awareness. HTTP has some headers
(like Accept-Encoding, Accept-Language, Content-Language, Content-Encoding,
Content-Type, etc.) that define message properties
essential for some types of server processing.

- Oskar

> -----Original Message-----
> From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
> [mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Mark 
> Nottingham
> Sent: Friday, April 19, 2002 9:46 PM
> To: The Purple Streak (Hilarie Orman)
> Cc: Oskar Batuner; Markus Hofmann; ietf-openproxy(_at_)imc(_dot_)org; 
> LMM(_at_)acm(_dot_)org
> Subject: Re: no-transform & Warning
>
>
>
>
> I'd characterise CC: no-transform as an explicit directive, not as an
> implicit contract. Or are you saying that HTTP itself is an implicit
> contract?
>
>
> On Friday, April 19, 2002, at 05:03  PM, The Purple Streak (Hilarie
> Orman) wrote:
>
> > I don't see why a ruleset is less reliable than an implicit contract.
> >
> > Hilarie
> >
> > Mark Nottingham wrote:
> >
> > > I think Oskar is referring to [1].
> > > I agree that in a surrogate (gateway) scenario, where there is an
> > > out-of band contract regarding message handling between the origin and
> > > the intermediary, Cache-Control: no-transform in a request, as well as
> > > the generation of transform-related Warnings, can be safely ignored
> > > (if both parties desire that behavior, of course).
> > > However, a proxy is a different kettle of fish; to be HTTP compliant,
> > > proxies encountering no-transform "MUST NOT change any aspect of the
> > > entity-body that is specified by these headers, including the value of
> > > the entity-body itself." [2]  I'd argue that even a proxy with an OPES
> > > ruleset from whoever's driving the User-Agent can't ignore this
> > > requirement; it places too much trust in what is often a heuristic -
> > > the ruleset - at the expense of directly associated, declared
> > > information to the contrary.
> > > Looking at the IAB "considerations" for OPES [3], it seems that
> > > no-transform and Warning make significant inroads into the requirement
> > > to be non-blocking, as well as that for notification. I can think of
> > > no better way to allow clients to specify that a message should not be
> > > transformed, as well as notify them that an entity has been changed;
> > > using an already-specified mechanism assures that at least
> > > theoretically, OPES-ignorant HTTP implementations can still
> > > interoperate with OPES intermediaries.
> > > Regarding the scope of "Cache-Control", "cache" isn't used with great
> > > precision in this part (and perhaps some others) of 2616; the language
> > > [2] clearly scopes no-transform as applying to caches *and* proxies,
> > > not just cache implementations.
> > > 1. http://www.terena.nl/conf/wcw/Proceedings/S4/S4-3.pdf
> > > 2. http://rfc2616.x42.com/ -  Section 14.9.5
> > > 3. http://rfc3238.x42.com/
> > > On Friday, April 19, 2002, at 02:08  PM, Oskar Batuner wrote:
> > > > I think Cache-Control headers and related response codes should be
> > > > applied
> > > > exactly to the subject they claim - cache control. The extended use
> > > > of HTTP
> > > > as a base protocol results in temptation to overload semantics of
> > > > existing
> > > > headers. Mark Nottingham pointed one example of such overload about a
> > > > year
> > > > ago (forgive me if I'm wrong with dates). Mark has posted a document
> > > > explaining why use of cache control headers is bad in origin-surrogate
> > > > context: semantic roles of HTTP client and server are different from
> > > > the
> > > > surrogate-origin server case - they have a special trust
> > > > relationship, and
> > > > cache control part of HTTP should better be preserved to manage
> > > > downstream
> > > > caches.
> > > >
> > > > The same approach should be taken for the callout protocol. The proxy
> > > > that
> > > > is running OPES rules serves as a callout gateway. According to the
> > > > OPES
> > > > intentions and IAB guidelines it has an explicit permission to perform
> > > > certain actions - that is, special relationship with either origin
> > > > server or
> > > > the end user. Cache control directives should be preserved for caches
> > > > that
> > > > may occur between OPES gateway and end user - otherwise there is no
> > > > mechanism left for content producer to control intimidate cache
> > > > behavior.
> > > > Callout participants and callout protocol SHOULD NOT try to interpret
> > > > such
> > > > directives.
> > > >
> > > > One additional implication is that in some scenarios OPES server (and
> > > > implicitly OPES gateway) may act as an authorized surrogate content
> > > > producer. In this scenario cache control directives MAY by altered to
> > > > reflect the changed content semantics. The way to handle them was
> > > > very well
> > > > described in Mark's document mentioned above. I do not remember what
> > > > happened to it, I'm afraid it just expired as a draft. Again, sorry
> > > > if I'm
> > > > wrong. Mark MAY shed more light on the fate of this document.
> > > >
> > > > - Oskar
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
> > > > > [mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of 
> > > > > Markus Hofmann
> > > > > Sent: Tuesday, April 16, 2002 2:34 PM
> > > > > To: Mark Nottingham
> > > > > Cc: ietf-openproxy(_at_)imc(_dot_)org; LMM(_at_)acm(_dot_)org
> > > > > Subject: Re: no-transform & Warning
> > > > >
> > > > >
> > > > >
> > > > > Mark Nottingham wrote:
> > > > >
> > > > > > I was talking about placing a requirement on the OPES server
> > > > > > implmentation, not the callout protocol itself. I.e., the protocol
> > > > > > can
> > > > > > be agnostic, but the thing that stuffs HTTP messages into it had
> > > > > > better
> > > > > > understand the semantics of HTTP.
> > > > >
> > > > > Yup, this I agree with, building the application semantic around a
> > > > > generic protocol, rather than building it into the protocol itself.
> > > > > It
> > > > > was not clear to me whether people thought of making the callout
> > > > > protocol itself aware of the encapsulated application protocol.
> > > > >
> > > > > -Markus
> > > -- Mark Nottingham
> > > http://www.mnot.net/
> --
> Mark Nottingham
> http://www.mnot.net/