RE: OPES protocol, pre-draft

If you are going to allow the callout processor to have that much
control, then it should be a fully general engine and be able to
select the transport protocol, port numbers, application protocol,
etc.  Heck, it should be able to open the connections itself.  I'd
presented this concept at one of the pre-WG meetings, as an additional
work item that might go onto a charter someday, but there was no
interest.  It's still a fine idea, but not for this WG.

The very focused approach of in-the-flow content adaptation that we have
now is a good one, and it reflects current practice and engineering
principles that are known to work very efficiently.  In this model,
the communication control point is the OPES box, and it is not slaved
to the callout servers.  The OPES rules can be used to change the source
and destination, and the OPES box is the most efficient place to accomplish
that function.

Spreading the essential control functions over a set of callout servers sets
up all kinds of configuration nightmares that will hinder adoption of
OPES.

Hilarie