[Top] [All Lists]

Re: comments on draft-dracinschi-opes-callout-requirements-00

2002-03-20 10:54:46

I would imagine that caching must be possible at each stage of the processing chain, so that you can compose things like

  svc1 -> cache -> svc2 -> cache
  svc1-> svc2 -> cache

depending on the particular situation.

This makes the cache effectively a local service itself, rather than an assumed part of the OPES intermediary. IMO that approach is more flexible and more clearly defined. It would require that a well-defined caching model be specified, but would not limit us to one caching model.

The requirements below lead to the need to compose a cache key based upon a fairly large variety of input. If the approach above is taken, it would best be communicated to the cache as a parameter. This, in turn, raises the need for out-parameters from callouts. E.g.,

  service chain:   svc1         ->     cache
  in parameters:   foo=boo             cachekey=abc,def
 out parameters:   cachekey=abc,def

All that would be needed, then, would be a way to hook up the out-parameters from svc1 to the in-parameters from svc2 in the ruleset (probably with some sort of variable, although an approach using URIs and/or XML IDREFs might be possible).

On Wednesday, March 20, 2002, at 02:37  AM, Frank Berzau wrote:

Responses could be cacheable for just a subset of requests. Example
could be a URL filtering service that returns different responses for
specific groups of users. This becomes an important aspect when looking
at section 3.2.6. If a callout server aggregates multiple responses it
must not only use the earlist expiration, it must also ensure the most
specific caching rule is applied. In some cases there may be situations
where such diverse cacheability rules cannot be contaminated, e.g.
server 1 does language translation and it flags all responses cacheable
per language (as found in the user-agent header). Service 2 does URL
filtering and flags responses be cacheable per LDAP user group. How
should the callout server aggregate this?

Thanks, Frank

-----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 
Sent: Friday, 01. March 2002 21:16
To: Mark Nottingham
Cc: OPES list
Subject: Re: comments on draft-dracinschi-opes-callout-requirements-00

Mark Nottingham wrote:

Perhaps it would be helpful to clarify the interactions between a)
the encapsulated protocol b) the OPES service and c) the callout
protocol. Caching touches all of these in different ways, and that
might be causing the confusion here.

That's a good idea, because there are quite some dependencies between
the various cachability rules (e.g. the possibly modified response
from a callout server must NOT be cached longer than indicated in the
original response from the origin server etc.). We struggeled quite a
bit ourselves when discussing this, so we need some clear
considerations here.


Mark Nottingham

<Prev in Thread] Current Thread [Next in Thread>