Like an ICAP control protocol? I'd thought of the sideband control
protocols as being possible actions, but only in the context of
proxying, not in a more general sense.
Errh, now are the processing points
becoming part of the box configuration? A proxy is a 4-point proxy-type
box, a mail gateway is a two-point gateway-type box, etc.?
Hilarie
"Maciocco, Christian" <christian(_dot_)maciocco(_at_)intel(_dot_)com>
05/04/01 04:47PM >>>
In the original draft OPES had been targeted at proxies were the 4 points
clearly map well. However OPES might run on devices which are not proxies,
and should allow flexibility in defining processing points (that still
represent the same meaning for all parties).
For example is there a need to allow "side point" which would be used to
control or feed data to a current service running on one of the 4 processing
point ?
-----Original Message-----
From: Andre Beck [mailto:abeck(_at_)bell-labs(_dot_)com]
Sent: Friday, May 04, 2001 1:26 AM
To: Rajnish Pandey
Cc: Hofmann(_at_)bell-labs(_dot_)com; ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: Processing Point
Rajnish,
Suggestion : We can put such rules at point 3. And
rules at point 3 should
be always considered, irrespective of object coming from
origin server or cache.
This would help us in taking advantage of cache.
I think we have to differentiate between services that generate a
user-specific response and those that don't.
User-specific services usually modify Web objects depending on certain
user characteristics, for instance if the user's native language is
German, then all Web pages are translated to German or if the
user's Web
access device is a Nokia cell phone, then all requested Web
objects are
adapted to fit the screen of the user's Nokia cell phone.
The second category of services modify Web objects equally for all
users. For example, a virus scanning service removes the same viruses
for all users. Or a bandwidth-saving service may compress all
Web pages
with gzip before they get sent to the users.
Rules that trigger services of the non-user-specific kind should be
processed at processing-point 3 because the service execution
result may
automatically end up in cache if the caching proxy decides
that the Web
object is cacheable. These cached objects would subsequently be served
to other users as well.
Rules that trigger user-specific services should be processed at
processing-point 4. The service execution results at point 4
could still
be cached. However, they would be cached by the service itself rather
than by the caching proxy. The same is true for the retrieval
of such a
cached Web object. The caching proxy wouldn't know what
object to serve
to the client because it doesn't know the user's characteristics like
preferred language etc. Therefore this would probably require
a service
at point 1 which gets triggered for certain user requestss and would
then check for a cached Web object that matches the user's
characteristics.
Comments?
-Andre