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

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.

Disadvantages:
   - 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/>".

Advantages:
  - Part of the message, therefore easy to persist
Disadvantages:
  - 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.

Disadvantages:
   - 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.

Advantages:
   - Applicable to any MIME-based or MIME-like transport
Disadvantages:
   - 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".

Advantages:
   - treats MTOM as an encoding, which several people have said it most 
resembles
   - easy to layer in alternate encodings
Disadvantages:
   - format-specific encodings, whilst not specifically discouraged, are 
unusual
   - specific to HTTP (although other transports may have similar 
concepts)
   - 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; 
content="application/soap+xml"
Advantages:
   - 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
Disadvantages:
   - 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".

Disadvantages:
  - 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