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

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

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Mon, 18 Aug 2003 11:02:21 -0700
To: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Message-Id: <1D2D264E-D1A6-11D7-8440-00039396E15A@bea.com>

On Tuesday, July 29, 2003, at 03:26  PM, Mark Nottingham wrote:

> * Implicit
> Whenever a multipart/related MIME message with an application/soap+xml 
> media type is encountered, it should be processed for MTOM-style 
> includes.

   - Doesn't allow the possibility of other uses of MIME, revision of 
the mechanism, or alternate encodings
   - MTOM messages are not self-describing on the wire

> * 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/>".

  - Part of the message, therefore easy to persist
  - Detecting MTOM messages for dispatch expensive
  - Binding features should be surfaced in the binding

> * New HTTP Header
> Need for processing will be flagged by a new HTTP header, e.g., "MTOM: 
> process" at the top level of the MIME message.

   - HTTP-specific (although it could easily be adapted to other 
MIME-based or MIME-like transports)
   - Some implementations *may* have difficulty accessing HTTP headers; 
there are no conventions for persisting arbitrary HTTP headers

> * New MIME Header
> Need for processing will be flagged by a new MIME header, e.g., "MTOM: 
> process" associated with the root (SOAP) part of the MIME message.

   - Applicable to any MIME-based or MIME-like transport
   - Unknown MIME headers may be dropped in some situations (need to 
check - believe they're fairly esoteric)

> * HTTP Content-Coding
> Need for processing will be flagged by use of a HTTP content-coding, 
> e.g., "Content-Encoding: mtom".

   - treats MTOM as an encoding, which several people have said it most 
   - easy to layer in alternate encodings
   - format-specific encodings, whilst not specifically discouraged, are 
   - specific to HTTP (although other transports may have similar 
   - integrating the HTTP and SOAP stacks in some implementations to 
take advantage of MTOM *may* be more difficult than otherwise

> * New MIME Content-Type
> Need for processing will be flagged by the use of a different 
> content-type for the root (SOAP) part; e.g., 
> "application/soap-mtom+xml".

An alternate media type might be "application/mtom+xml; 
   - Unambiguous identification of MTOM messages
   - Treats MTOM as a separate format from SOAP, that can be transformed 
into SOAP with the proper processing
   - Applicable to any transport that is MIME-based or MIME-like
   - Registering new media types can be onerous (but perhaps this should 
be fixed in the proper place)

> * MIME Content-Type Parameters
> Need for processing will be flagged by the use of a parameter on the 
> "application/soap+xml" media type in the root (SOAP) part; e.g., 
> "application/soap+xml; mtom".

  - Media type parameters shouldn't flag things that fundamentally 
change the nature of the format, and arguably this does.
  - Requires changing the "application/soap+xml" registration (in 
process, but already referenced from the REC - is this an issue?)
Received on Monday, 18 August 2003 14:02:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:24 UTC