ietf-openproxy
[Top] [All Lists]

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

2001-06-12 13:23:58

Is it a requirement that the entire message must be parsed in order
to extract any particular part?

If you were looking for some particular entry in the soap header section,
you'd find the beginning of the header entries (which must be the first
child of the soap envelope if there is a header section).  Then for each top
level element inside the soap header element, you'd check if it was the one
you were looking for and skip it if it wasn't (skip by looking for the
matching end tag for what you are skipping).  When you find the header
element you want, you'd grab that XML inside it and parse it.

-----Original Message-----
From: Hilarie Orman [mailto:HORMAN(_at_)volera(_dot_)com]
Sent: Sunday, June 10, 2001 9:33 PM
To: ietf-openproxy(_at_)imc(_dot_)org; wayne(_dot_)carr(_at_)intel(_dot_)com
Subject: RE: Re: Q: Why is ICAP limited to HTTP



Is it a requirement that the entire message must be parsed in order
to extract any particular part?

Hilarie

"Carr, Wayne" <wayne(_dot_)carr(_at_)intel(_dot_)com> 06/08/01 02:46PM >>>
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