ietf-openproxy
[Top] [All Lists]

RE: Chaining of Callout Servers

2002-07-23 02:11:44
Hi,

I for one, who was in favor of the chaining "feature", gave it some thought
and realized 
that it is going to make things more complicated. It will add more massages,
and will 
require the OPES engine to act as server (B needs to notify the results,
etc).

So I suggest to remove this requirement (at least from this stage).

Yours,

Haim Rochberger
Comverse.

-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Tuesday, July 23, 2002 5:29 AM
To: OPES Group
Subject: Chaining of Callout Servers



Hi,

we want to wrap up the existing three OPES WG documents and issue a WG 
last call as soon as possible!! In order to do so, we need to find 
consensus on the few remaining open issues that came up during the 
meeting last week!

One issue that affects all three documents is the question whether we 
should allow/support chaining of OPES callout servers. Chaining of 
OPES callout servers refers to a scenario in which an OPES processor 
forwards a message to callout server A, and callout server A forwards 
the same message for (additional) servicing to callout server B.

We had a brief discussion on this issue on the general OPES mailing 
list before, in the context of OPES callout protocol requirements, and 
the feeling somehow was to *not* require protocol support for callout 
server chaining. However, the scenarios doc (and the architecture 
doc???) still have the notion of server chaining in.

Question to the group: What's the consensus - should we explicitly 
allow/support callout server chaining? If yes, what are the impacts 
with respect to complexity, reliability, fault-tolerance, data 
integrity, privacy, security, etc? What are the specific scenarios in 
which such a mechanism would be beneficial? And would the expected 
benefits outweigh the additional complexity?

Any opinions on that?

Cheers,
   Markus
<Prev in Thread] Current Thread [Next in Thread>