Options for flagging MTOM processing (consolidated feedback)

This e-mail consolidates the feedback received regarding options for 
flagging MTOM processing.

* 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 [Mark Nottingham]


* 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 Nottingham]

> 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. [Noah Mendelsohn]


* 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 [Mark 
> Nottingham]


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

> Is this advisable? Couldn't it be stacked with, say, gzip or other 
> content codings? There was discussion yesterday on limitations of HTTP 
> content codings wrt binary infosets. Perhaps MTOM would also benefit 
> from that? [Robin Berjon]

> You can have multiple, serialized content-codings, e.g., 
> "Content-Encoding: mtom, gzip".
>
> I've heard the following concerns raised about the content-coding 
> approach:
>   - The notion of a content-aware/-specific content-coding is 
> troubling to some. It's not explicitly ruled out or even discouraged 
> by HTTP, but it is a bit odd.
>   - This solution is specific to the HTTP, and would need to be 
> reinvented for other transports.
>   - Although it's a property of the HTTP entity, there's no recognized 
> way to persist content-coding information on disk, so it would be 
> implementation-specific; e.g. if "foo" uses content-coding "gzip", it 
> could be persisted as "foo.gz", but that's just a local convention. I 
> don't see this as a huge drawback, especially since we're doing MTOM 
> as a binding feature, but others might. [Mark Nottingham]

> 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 [Mark 
> Nottingham]


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

> 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) [Mark Nottingham]


* 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?) 
> [Mark Nottingham]


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Monday, 8 September 2003 16:59:44 UTC