XML is not 8bit clean, and
therefore is not suitable for encapsulating arbitrary content within
an application that operates at router speeds. That's also why most
SOAP implementations are vulnerable to denial-of-service attacks
simply by selective abuse of the XML data.
If you believe this to be the case, please raise this as an issue with
the XML Protocol WG on xml-dist-app(_at_)w3(_dot_)org(_dot_)
It is a very well known fact of XML. But since the XML Protocol WG is,
by definition, restricting themselves to a buzzword-compliant syntax
rather than one chosen for its protocol capabilities, there really isn't
any point in notifying them.
I have trouble believing that iCAP justifies the overhead of an HTTP
syntax, let alone XML on top of HTTP.
I'd point out that SOAP is not bound to the HTTP; that is just the first
binding, and I see signficant numbers of people wanting to move away
from it. Also, SOAP isn't intended for arbitrary data; that's what SOAP
w/ attachments and DIME (for example) are for. They aren't really good
solutions for the problem iCAP attempts to address, but they should be
noted.
They are very recent and untried, though I agree that the purpose of them
is to enable encapsulation. I prefer TCP for that, or SCP if there is a
need for mutiplexing across a single connection. Layering application
protocols is a waste of bits.
That being said, I had always mused that SOAP could be used as a
separate control channel between the client and server, leaving the
protocol stream as-is. This would allow the protocol messages to remain
unencapsulated, keeping all vectoring-specific information out of band.
Not sure how practical this is, but it seems the most realistic way to
use SOAP and avoid all of the problems of encapsulating a protocol.
That would be SCP -- far more efficient and actually designed for that
purpose.
Just to be clear, when I was first introduced to iCAP (September 1999),
the first comment I had was that it didn't make sense to use HTTP for
this purpose. I didn't think that anyone would want to do iCAP across an
Internet connection (as opposed to a LAN between the iCAP client and
iCAP server), so UDP or reliable ordered multicast would have been my
design choice.
....Roy