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