W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2003

Re: Options for flagging MTOM processing (pros and cons)

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 27 Aug 2003 10:43:59 -0400
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Message-ID: <OFAE163DC0.C08CF221-ON85256D8E.00738F06@lotus.com>

Mark Nottingham writes:

> > * In-XML
> > Need for processing will be flagged by an artifact in the XML payload; 

> > e.g., a SOAP header block such as "<xbinc:DoIncludes/>".
> 
> Advantages:
>   - Part of the message, therefore easy to persist
> Disadvantages:
>   - Detecting MTOM messages for dispatch expensive
>   - Binding features should be surfaced in the binding

Mark:  thanks for pulling all of these together.  I am largely in 
agreement with your analysis.  I think there is one more disadvantage for 
the case above:

- presuming the envelope part itself is marked application/soap+xml, we 
are in my opinion somewhat misusing that media type.  While it's true that 
the contents syntactically resemble a SOAP envelope, they are not in fact 
a SOAP envelope subject to SOAP processing until the include processing is 
performed. 

While I can understand either point of view, I would prefer to encourage 
use of the application/soap+xml type specifically for the case where what 
you have is an envelope ready for soap processing.

> An alternate media type might be "application/mtom+xml; 
> content="application/soap+xml"

You are more expert in these things than I, but I think we should at least 
consider application/soap+mtom+xml or application/soapmtom+xml.  I'd like 
to better understand the tradeoffs relative to using content= as you 
suggest above.  Thanks!

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------
Received on Wednesday, 27 August 2003 10:49:47 GMT

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