ietf-openproxy
[Top] [All Lists]

Re: Comparison of ICAP and SOAP

2001-06-28 15:44:37

The existence of a multiple implementations is a good thing but it
is the only criteria specified. That is not a very good one to evaluate
a protocol.

The purpose of multiple implementations isn't to evaluate the protocol.
It is to evaluate the specification of the protocol.  In this forum,
it is much more important that the specification represent "the truth"
regarding correct implementation of the protocol than it is that the
protocol itself be the best design for the problem.  I need to know the
difference between protocol features that can be depended on for
interoperability and those that just happen to be in a major vendor's
implementation of the protocol.  I am perfectly willing to let the market
decide what is the best protocol -- I just need to know the standard
against which implementations of the protocol will be judged.

How about coming to the meeting (assuming things happen
in London) and lead a discussion on what good criteria for measuring these
protocols would be?   Mark has already signed up for one item...

That is an excellent question, and one that I feel should be addressed
in the charter if this WG is ever to be of manageable scope, but I won't
be in London.  In any case, application-level routing can only be evaluated
in terms of the application running on top of it.  Large-grain data flow
messages versus small-grain control messages will partition the design
space, as will incremental transformations versus batch-constrained
transformations (applications where the filter must receive the entire
message before knowing the answer).  I very much agree with the comment
that no single callout protocol will be "right" for all applications,
but I disagree that an RPC style of callout should be preferred over
a simple forking of the protocol stream.

In my own application space (Web), my desire is that the OPES mechanism
not add any significant (user noticed) latency for a transformation that
is capable of incremental processing.  Otherwise, there is no situation
in which I would use the standard.  Next comes simplicity in order to
make parsing efficient for high-scalablity processing and to reduce the
probability of security holes appearing due to complex implementations.
Finally, the OPES intermediary must be able to process the identity
(null) transformation as fast as a normal Web server can transfer 
non-static content.

....Roy