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
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.
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Mark
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;
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
On Friday, April 19, 2002, at 05:03 PM, The Purple Streak (Hilarie
I don't see why a ruleset is less reliable than an implicit contract.
Mark Nottingham wrote:
I think Oskar is referring to .
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."  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 , 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
 clearly scopes no-transform as applying to caches *and* proxies,
not just cache implementations.
2. http://rfc2616.x42.com/ - Section 14.9.5
On Friday, April 19, 2002, at 02:08 PM, Oskar Batuner wrote:
I think Cache-Control headers and related response codes should be
exactly to the subject they claim - cache control. The extended use
as a base protocol results in temptation to overload semantics of
headers. Mark Nottingham pointed one example of such overload about a
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
surrogate-origin server case - they have a special trust
cache control part of HTTP should better be preserved to manage
The same approach should be taken for the callout protocol. The proxy
is running OPES rules serves as a callout gateway. According to the
intentions and IAB guidelines it has an explicit permission to perform
certain actions - that is, special relationship with either origin
the end user. Cache control directives should be preserved for caches
may occur between OPES gateway and end user - otherwise there is no
mechanism left for content producer to control intimidate cache
Callout participants and callout protocol SHOULD NOT try to interpret
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
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
wrong. Mark MAY shed more light on the fate of this document.
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of
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
be agnostic, but the thing that stuffs HTTP messages into it had
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.
was not clear to me whether people thought of making the callout
protocol itself aware of the encapsulated application protocol.
-- Mark Nottingham