At 04:13 PM 1/8/01 -0800, Mark Nottingham wrote:
The latest revision of the ICAP specification attempts to address
many of these issues; I'd encourage Graham to have a look at it to
see if his opinion changes. That having been said, I don't disagree
with the main point he raises.
I've taken a quick look: the specific points about "but is it HTTP?" and
separation of ICAP protocol from payload do seem to have been addressed.
As for whether the protocol elements are applicable to use with other
protocols, I'd need to look more deeply. As drafted, ICAP is still quite
specific to HTTP request handling.
As for using HTTP elements as a substrate for defining the ICAP protocol, I
have reservations (though this too would be subject to closer
examination). As a protocol, HTTP has a lot of complexity and subtlety
that may not be appropriate for a "lightweight remote procedure call" that
is the basis for ICAP. To be clear about the similarities and differences
will, I think, require great care. For example, why does a "lightweight
remote procedure call" mechanism import HTTP cache-control semantics?
An alternative approach might be to build a protocol on the BEEP substrate,
which is quite clear about the problems it does and does not address.
In summary: it may be that ICAP is a reasonable starting point for OPES,
but I don't think that's sufficiently clear to be written into the charter.
#g