W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2001

RE: text/xml for SOAP is incorrect

From: Andrew Layman <andrewl@microsoft.com>
Date: Wed, 19 Sep 2001 16:21:34 -0700
Message-ID: <C3729BBB6099B344834634EC67DE4AE102623B0E@red-msg-01.redmond.corp.microsoft.com>
To: <xml-dist-app@w3.org>
But see the SOAP with Attachments specification.[1]  There are good
reasons to rapidly dispatch, but as this spec shows, there are also good
reasons to use MIME multipart.  For example, ebXML uses it.  I believe
that one of the motivations of the SOAPAction HTTP header was to allow
the rapid dispatch without sacrificing MIME multipart.
 
[1] http://www.w3.org/TR/SOAP-attachments

	-----Original Message-----
	From: Mike Dierken [mailto:mike@DataChannel.com] 
	Sent: Wednesday, September 19, 2001 1:53 PM
	To: Andrew Layman; xml-dist-app@w3.org
	Cc: dave@scripting.com
	Subject: RE: text/xml for SOAP is incorrect
	
	


	> Another question, which may have been addressed in a message I

	> overlooked, but what if a SOAP message per the
application/soap+xml 
	> proposal were contained in a MIME multipart structure?  In
this case, 
	> the top-level MIME type would make no mention of SOAP (or
would it? 
	> How?)  If so, how would a processor of the message make the 
	> correct and 
	> rapid messing-with or dispatching decisions? 
	If the MIME 'envelope' (outer content-type in multipart/related)
isn't SOAP the the message isn't SOAP. 
	If intermediaries are built to look at portions of a message,
they have to scan the stream... (which is pretty efficient with a
Boyer-Moore algorithm.)

	mike 
Received on Wednesday, 19 September 2001 19:24:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT