RE: Shortcuts

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, 11 Apr 2003, Abbie Barbir wrote:

> Should we call it distributed OPES processor (where performance does
> not count)

I do not think there is anything special here that deserves a new
name. It is simple a case of forwarding an application message to the
next application protocol hop (possibly determined by processor
rules). The first OPES processor would not even know that the second
hop is an OPES processor. I do not see any performance penalty here
either.

The "black hole" case I described at the very end may be worth
documenting somewhere though.

Alex.

> > -----Original Message-----
> > From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
> > Sent: Friday, April 11, 2003 12:03 AM
> > To: ietf-openproxy@xxxxxxx
> > Subject: Re: Shortcuts
> >
> >
> >
> > On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote:
> >
> > > I had a returned thought on the issue of whether or not data had to
> > > complete the loop between the OPES processor and the
> > callout server.
> > > If the proxied protocol is a store-and-forward type, like
> > SMTP, then
> > > it seems that the callout server might, quite properly, send
> > > transformed messages directly to an application endpoint
> > (SMTP server)
> > > without going back through the OPES processor.
> > >
> > > If this is proper, should we document it.  If it is
> > improper, can we
> > > say why?
> >
> > Excellent question!
> >
> > If a callout server accepts application message and then just
> > forwards an adapted version elsewhere, it is not (should not
> > be) a callout server. It is an OPES processor! Thus, it is
> > absolutely proper to do that as long as the entity in
> > question does not pretend to be a callout server and obeys
> > all processor requirements.
> >
> > Here is what you get in that case:
> >
> >  -- (SMTP) --> OPES         --> (SMTP) --> OPES        --> (SMTP)
> >                processor 1                 processor 2
> >
> > Which is perfectly fine and is obviously beyond OCP scope
> > (OCP is not involved here).
> >
> > If, for some unnatural reason, the same thing is implemented
> > using OCP, it may still be OPES-legal as long as both OPES
> > agents know what they are doing:
> >
> >                                           callout server
> >  -- (SMTP) --> OPES         --> (OCP) --> _and_ OPES     --> (SMTP)
> >                processor 1                processor 2
> >
> > Essentially, "adaptation service" here means "I took care of
> > it, forget it". This is OK as long as processors cooperate.
> > Note that the callout server would be required to respond
> > with that "I took care of it" application message to its OPES
> > processor 1 (that application message/response will probably
> > have no payload though, just metadata). No need to documented
> > this convoluted case, IMO.
> >
> > A somewhat similar but more realistic example with an "I took
> > care of it" response would be a "black hole" service (e.g., a
> > SPAM filter):
> >
> >  -- (SMTP) --> OPES         --> (OCP) --> callout
> >                processor 1                server
> >
> > The latter might be worth documenting in an "SMTP adaptation
> > using OPES" draft.
> >
> > HTH,
> >
> > Alex.
> >
> >
> >
>