Roy,
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_)
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.
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.
Cheers,
--
Mark Nottingham
http://www.mnot.net/