Subject: Re: Comparison of ICAP and SOAP

From: John Martin <[email-masked]>
Date: Mon, 09 Jul 2001 13:56:11 +0200

Apologies for the delay in responding. I believe that Mark's summary is 
pretty accurate but I would add one clarification. SOAP encompasses much 
broader scope that iCAP. SOAP is a whole architecture for messaging; iCAP 
is a very simplified vectoring protocol.

iCAP is a way of getting an object X from A to B. Specifically it does not 
define how this decision is made - it is simply defines the protocol by 
which the content is transferred.

iCAP shares a lot more functionality with CVP than SOAP. (In fact, the 
original work for iCAP was titled "Simplified HTTP Vectoring Protocol").

Rgds,
John

At 04:15 PM 25/06/01 -0700, Mark Nottingham wrote:

>In a nutshell:
>
>ICAP is a means of encapsulating HTTP inside of HTTP, to allow
>messages to be 'vectored' from an intermediary to an ICAP server for
>processing, and then sent on their way. It also defines where those
>messages may be vectored from the intermediary. I believe that its
>primary design goal is efficiency, but that's different depending on
>who you talk to.
>
>SOAP can IMHO best be thought of as an XML messaging convention, with
>some protocol-like attributes (such as the RPC convention). SOAP is
>designed to be transport-dependant; while its most common use is
>across HTTP, it can be used with other underlying protocols like SMTP
>or raw TCP. SOAP is designed to allow targetting of blocks of the XML
>to be processed by specific intermediaries. Its primary use cases are
>'Web Services', i.e., the machine->machine Web, e.g., stock quote
>services, order queuing, etc.
>
>So, SOAP could be used to implement ICAP, but then again so could
>BEEP. Not too many of the ICAP people are interested in using SOAP,
>though, as their requirement is to allow 'wire-speed' vectoring and
>processing, and they find the overhead of XML unacceptable.
>
>Cheers,
>
>
>
>On Mon, Jun 25, 2001 at 04:11:01PM +0800, Wanghong Yuan wrote:
> > HI, All
> >
> > Where can I find some materials or dicussion on ICAP and SOAP? I think
> > both of them address somewhat the content adapation problem in Internet.
> > Thanks.
> >
> > Wanghong
> >
>
>
>Speaking for myself,
>
>--
>Mark Nottingham, Research Scientist
>Akamai Technologies (San Mateo, CA USA)

---------------------------------------------------------------
Network Appliance           Direct / Voicemail: +31 23 567 9615
Scorpius 2                                 Fax: +31 23 567 9699
NL-2132 LR Hoofddorp               Main Office: +31 23 567 9600
---------------------------------------------------------------

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 9 Jul 2001 14:38:02 +0100 (BST)

On Mon, 9 Jul 2001, John Martin wrote:

> I would add one clarification. SOAP encompasses much 
> broader scope that iCAP. SOAP is a whole architecture for messaging;

*architecture*?

it's a simple, lightweight instance of XML use along with a bunch of
kludged http headers.

As its name suggests, it has more to do with plumbing than
architecture.

L.

I think I've finished architecting this email now.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Randy Bush <[email-masked]>
Date: Mon, 09 Jul 2001 21:12:03 -0700

> it's a simple, lightweight instance of XML use along with a bunch of

hey, don't knock it.  where else can you get remote procedure call,
intermediate proxies which can remove and add message/command content,
and not one whiff of authentication or authorization to pollute it
with silly security ideas?

can you say loaded fusion bomb?

randy