RE: Re: Q: Why is ICAP limited to HTTP

I think SOAP is much simpler than people may think.  Here's a quick made up
example.  I'll make this slightly more complicated to show multiple
features.  The parts of the example starting this "t:", "m:" and "y:" are
the content of the message being sent and can be any arbitrary content
anyone defines using XML. The rest is the soap framework itself and that's
pretty simple - an envelope containing a header section and a body section.
The contents of the header and body are what we or a service provider would
get to make up.

--- start of example ---
POST /PriceQuote HTTP/1.1
Host: www.prettygoodfoods.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
  <SOAP-ENV:Header>
    <t:Transaction
      xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
          5
     </t:Transaction>
    <y:Archive
      xmlns:y="some-other-URI" SOAP-ENV:mustUnderstand="1" />
    </SOAP-ENV:Header>
   <SOAP-ENV:Body>
       <m:GetSuggestedPrice xmlns:m="Some-URI">
           <item>
                        muffins
                </item>
       </m:GetsuggestedPrice>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--- end of example

Important features:
1. Envelope contains header and body sections.
2. Header can be used to contain messages to intermediaries.  Can include
any number of header entries.  Can indicate who should process each header
entry.  Can indicate whether understanding the header is optional.  There
are two header entries above and both must be understood.  Intermediaries
can process headers and remove them or add new headers.
3. Body contains message intended for ultimate recipient.  Like headers
there can be many body entries.
4. Contents of header and body can be XML from any arbitrary namespace.  So
each direct child can have a different namespace.  See the parts prefixed by
"t", "y" and "m" above.  
5. W3C's XML schema is used to define the formats for the component parts.
That can do things like specify a good deal of information about datatypes.
That may be of use to the ultimate user of the data.  It may send part
numbers that must match some format, but none of that needs to be understood
by an intermediary that gets one message (or an HTTP request) and responds
by sending a soap message to an intermediary.  
6. Soap also describes a way to use its asynchronous messages in RPC.
7. SOAP describes a binding for how to send it using HTTP.  Alternately the
messages could be sent using BEEP, etc..




> > From: "Hilarie Orman" <HORMAN(_at_)volera(_dot_)com>
> > To: <wilbertdg(_at_)hetnet(_dot_)nl>, <ietf-openproxy(_at_)imc(_dot_)org>
> > Subject: Re: Q: Why is ICAP limited to HTTP

> > 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.
> >
> > ICAP comes from a different design philosophy, one that says
> > that some protocols are best encapsulated within themselves.
> > HTTP with header extensions is almost enough.  ICAP 0.9
> > could be implemented within an HTTP server; ICAP 1.0 stepped
> > a hairsbreadth over the line and requires minor server
> > changes (newer servers may have enough power to accommodate
> > things like ICAP).
> >
> > 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.
> >
> > If a protocol has enough capabilities for self-reference, you can
> > build a "proxy plane" version of it out of existing 
> machinery.  That's
> > usually good, especially if you don't have to marshall the data
> > twice.  On the other hand, viewing it from the proxy viewpoint, it's
> > better to have one set of encapsulation routines and use those
> > for all protocols.
> >
> > Another design consideration is how much information the
> > encapsulation needs to carry about the inner material.  If the
> > naming scheme and other protocol dependent parameters
> > must be part of the encapsulation scheme, then the machinery
> > for handling the encapsulation may have to recapitulate much
> > of the original protocol anyway.
> >
> > For something as simple as SMTP, perhaps either approach
> > is viable.  For RTSP and its associated RTP streams, it's
> > much murkier.
> >
> > Hilarie
> >
> > > > > "Wilbert de Graaf" <wilbertdg(_at_)hetnet(_dot_)nl> 06/08/01 07:59AM >>>
> > Going through the ICAP specification, I wondered why ICAP is 
> limited to
> > HTTP. I understand it's focus is on HTTP, but I think it's 
> useful for other
> > protocols as well. For instance NNTP and SMTP.
> >
> > Would it make sense to incorporate these other protocols as well ?
> >
> > Thanks, Wilbert
> >
> > Btw. I do know that SMTP is hardly found 'on the edge' but ICAP could
> > definitely be useful there (eg. sieve, virus scanning, ).
> Michael W. Condry
> Director,  Network Edge Technology