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.

Hilarie

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 
> 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/