It seems there might be different ideas about what "chaining" means. From
the initial discussion here I was perceiving a chain of supplementary
servers behind the initial callout server where the presence of the 2nd,
3rd, nth server were somewhat hidden from the OPES processor.
What I see in your comments, Andreas, is something akin to a "star"
topology (actually it sounds a little similar to Mark Baker's stuff) where
a central authority handles the routing. However, by allowing the OPES
processor to create the list I'm starting to fail to see any reason for the
chain to exist (at least so far as OPES protocols are concerned, perhaps);
that sounds more like a ruleset being processed (A, B, C) rather than a
potential chain (A, A', A'').
Irrespective, I agree that chaining of callout servers per se. should be
excluded as a requirement at this stage.
Urgh, thanks Marshall ... I'm now going to spend a lovely sticky day
reading I-Ds ;-)
--On 29 July 2002 01:33 -0700 Andreas Terzis <aterzis(_at_)sbcglobal(_dot_)net>
wrote:
I would also be in favor of omitting chaining from the first version of
the protocol. As other people have mentioned the potential benefit of
chaining increases as the pipeline gets longer. Since I suspect that
initial deployments will have a small number of services (and therefor
short chains if any) we can always add support for chaining later.
BTW, I would also be in favor of explicitly creating the ordered list of
callout servers that are part of a chain at the OPES processor rather
than letting the first callout server to determine that. The main reason
is to try to keep the callout servers as simple as possible.
Regards,
-andreas
-----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
Hofmann
Sent: Thursday, July 25, 2002 3:12 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: To chain or not to chain
OK, it seems there's consensus towards starting with no chaining, but
keeping this option open for later exploration. This implies that the
protocol requirements draft does *not* have to include a requirement
to support chaining at the moment.
Taking this into consideration, it seems that the three drafts in
their current form are fine in this context and don't need further
additions (except, maybe, adding a little note to Section 3.5 in the
requirements draft??).
-Markus