Michael Brennan wrote:
>
>...
>
> Yes, but it wasn't particularly designed for that. The problem is easily
> addressed using MIME, as demonstrated by the SOAP With Attachments spec.
> So what's the problem with MIME?
I have no problem with MIME. In my mind, MIME is the alternative to XML
envelopes. The fact that you still need MIME sometimes when you use XML
envelopes serves as evidence to me that MIME should just be the default.
>....
> > * Binary data solutions not-standardized and perhaps
> > patent-encumbered.
SOAP with attachments and DIME are potentially patent-encumbered.
SOAP with attachments: "IBM may own patents or patent applications which
apply to the SOAP Attachments specification being submitted to the W3C.
If implementation of a W3C standard based on the SOAP Attachments
specification requires the use of IBM patents, IBM will grant, upon
written request, a non-exclusive license under such patents on
reasonable and non-discriminatory terms."
DIME: "The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights."
>...
> > * Merging and splitting payload from envelope requires XML
> > processing which is more expensive than MIME processing.
>
> Most of the systems I've seen interpret the entire infoset of the SOAP
> message at once. They don't extract a "document" from the body.
That will change as people start to use SOAP headers and have a
requirement to process a single header (perhaps for dispatching) before
they do anything with the body. This ability to target headers (and make
them mandatory) is the primary advantage of SOAP headers over MIME
headers.
* http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0128.html
>...
> The use of XML is quite convenient for a broad class of applications, in
> particular applications interested in processing modular data structures
> (which can be modeled with XML Schema) with some associated contextual
> info (such as authentication info) in a loosely coupled fashion.
How would using MIME instead of XML envelopes prevent you from
"processing modular data structures with ... in a loosely coupled
fashion." I've tried to demonstrate that using MIME allows you to be
MORE loosely coupled by allowing a single intermediary to work with a
header or the body without worrying about anything else in the message
that might confuse it.
The job of a protocol envelope is to separate things. MIME just seems to
do a better job of that than XML envelope strategies.
>... I don't see that proving
> there are large classes of problems it does not solve really invalidates
> SOAP's approach, unless it can be demonstrated that there are *not*
> large classes of problems it can solve or that there is an equivalently
> simple approach that addresses a superset of requirements.
Well I don't think anybody has really demonstrated benefits to the XML
envelope approach. Until they do why talk about segmenting the market
into things that MIME is good for and things that XML envelopes are good
for. You segment to meet different requirements. So far, there are no
different requirements.
> No document-centric approach, though, can fully address the same set of
> requirements that SOAP addresses. Any superior solution must just as
> effectively be able to support the same sort of modular,
> namespace-centric processing models that the SOAP envelope supports.
Namespace-centric processing is provided by XML, not by the SOAP
envelope. How would an XML payload in a MIME message disable
namepace-centric processing?
Paul Prescod
