Thanks Hilarie, that was certainly very helpful.
It does make sense to have an generic "protocol for encapsulating
another protocol". At the work, SOAP was suggested. A few of
us have discussed defining a more minimalist approach using
BEEP.
I'm not really in favor of encapsulating protocols and make ICAP this
protocol that carries all other's. I think from the call-out it's explicit:
- the icap-client processing the rules knows what protocol it's doing
- the icap-service, as identified by the the icap-uri, knows what protocol
to expect
In that case, both ends know what it's all about. It's just the call-out
mechanism itself that could be used at other places.
Should ICAP be extended to handle more protocols and become
the "protocol for encapsulating protocols"? I don't think so, because
it has been nicely tuned to HTTP.
Agree. But than it's only the call-out mechanism I'd like to have for other
protocols as well.
Wilbert