Is it a requirement that the entire message must be parsed in order
to extract any particular part?
"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
Content-Type: text/xml; charset="utf-8"
xmlns:y="some-other-URI" SOAP-ENV:mustUnderstand="1" />
--- end of example
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
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
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
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
"Wilbert de Graaf" <wilbertdg(_at_)hetnet(_dot_)nl> 06/08/01 07:59AM >>>
Going through the ICAP specification, I wondered why ICAP is
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 ?
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