Re: RE : draft-ietf-opes-ocp-core

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

On Tue, 26 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote:

> However, I think we need at least a way to tell the processor if
> it's allowed or not to cache specific adapted data.
>
> One example to explicit my need: having a filtering service, you may
> want unfiltered content (for any client profil) to be cached by the
> processor after the server call (to reduce load on this server), so
> the server has to be called before the processor cache mecanism.
> However, you will want potentially filtered content and
> corresponding adapted data not to be cached because it will be
> managed by specific server policy.
>
> So I suggest introducing at least an optionnal flag in DUM message
> telling processor not to cache the answer.

I agree that cache control is a desirable feature in many
environments. There are several related observations:

	- Some application protocols to not support the
	  notion of caching (e.g., SMTP).

	- Application protocols that support caching
	  usually have built-in caching controls (e.g.,
	  Cache-Control header in HTTP). These controls
	  are often quite sophisticated.

It looks to me that adding cache control features to OCP Core would be
wrong because some protocols do not have a notion of caching at all,
and those protocols that do already have extensive controls that OCP
Core would not be able to duplicate in a generic manner.

How about this:

	- Let OCP application bindings handle cache control
	  issue.

	- Recommend that an application binding relies
	  on existing application controls rather than
	  extend OCP.

Would that address your needs, including the filtering example you
gave above? Can the filter service alter Cache-Control headers of the
filtered responses appropriately?

Thanks,

Alex.