Re: no-transform & Warning
The message thread states that no-transform can be safely ignored
is there is an "implicit contract", but it cannot be ignored safely
if there is a ruleset explicitly stating that it can be ignored.
That's what I was taking issue with.
Mark Nottingham wrote:
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
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
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
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
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 Markus
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. It
was not clear to me whether people thought of making the callout
protocol itself aware of the encapsulated application protocol.
-- Mark Nottingham