SOAP using BEEP internet draft --
http://search.ietf.org/internet-drafts/draft-etal-beep-soap-00.txt
As Mark said, for binary data, soap with attachments carries the soap xml
part of the message using mime multipart-related.
-----Original Message-----
From: Mark Nottingham [mailto:mnot(_at_)mnot(_dot_)net]
Sent: Thursday, June 14, 2001 8:39 AM
To: Roy T. Fielding
Cc: wayne(_dot_)carr(_at_)intel(_dot_)com; ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: Q: Why is ICAP limited to HTTP
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/