Request for guidance on MIME and media types

The W3C XML Protocol Working Group is currently working on the Message 
Transmission Optimisation Mechanism (MTOM)[1], which allows more 
efficient transmission of SOAP envelopes [2] by changing their 
on-the-wire XML serialisation.

Registration of the "application/soap+xml" media type is currently 
under way, so that SOAP envelopes (i.e. the XML construct that SOAP 
defines) can be identified in MIME and MIME-like systems. We anticipate 
the need to likewise identify MTOM messages in these systems, and would 
like to solicit guidance about the best way to do so.

Whereas the XML 1.0 serialisation of SOAP is self-contained, MTOM 
serialisation will only use XML for a subset of the envelope data. 
Other portions of the envelope will be transmitted in separate binary 
entities, typically but not necessarily in a multipart/related MIME 
message, and those entities will be referenced with URIs from the 
envelope (which, when using multipart/related, would reside in the root 
part).

A simplistic example might be;

---8<---
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; 
type=application/soap_mtom+xml;
         start="<envelope01@example.org>"

--MIME_boundary
Content-Type: application/soap_mtom+xml
Content-Transfer-Encoding: 8bit
Content-ID: <envelope01@example.org>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="...">
<SOAP-ENV:Body>
   <!--- xml content here -->
   <Image type="image/jpeg"><Include xmlns="..."
     href="cid:binary01@example.org"/></Image>
   <!--- xml content here -->
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <binary01@example.org>

[binary image]
--MIME_boundary--
---8<---

Which could be transformed to this XML -

---8<---
<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="...">
<SOAP-ENV:Body>
   <!--- xml content here -->
   <Image type="image/jpeg">[base64-encoded image]</Image>
   <!--- xml content here -->
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
---8<---


The XML that is transmitted by MTOM is thus distinct from 
application/soap+xml in at least the following respects:

* It contains some but not all of the envelope data. Indeed, in the 
common case where multipart MIME is used, it's the entire package that 
conveys the same information as application/soap+xml.

* Its semantics are different from those of a SOAP envelope. The usual 
semantic for a SOAP envelope is to apply the SOAP processing model; the 
semantics of an MTOM envelope are to to resolve the link URIs to create 
a new Infoset, which is in turn processable by the SOAP model.

Therefore, it appears that the application/soap+xml media type, as 
currently defined, is not appropriate to describe the XML format 
created by MTOM.

We've considered several possible alternatives, including 1) use of a 
HTTP content-coding (which we rejected, both because content-codings 
are a HTTP-specific mechanism, whereas we intend to use this encoding 
in other protocols, possibly including MIME-based protocols, and 
because doing so would require labelling the HTTP entity with an 
"application/soap+xml" media type, which would mask the presence of 
multipart MIME), and 2) a MIME content-transfer-encoding (which we 
rejected because registration of new CTEs is discouraged by RFC2045).

Therefore, we believe that it would be most suitable to register a new 
media type, e.g., "application/soap_mtom+xml". This media type would 
identify the XML pre-MTOM processing (i.e., with the URIs to be 
referenced still embedded), possibly (but not necessarily) located 
inside a multipart/related package.

Note that a specification is being prepared that allows for the use of 
a similar "resolve the URI to insert binary characters" idiom in 
non-SOAP scenarios.  The general technique is documented at [3] under 
the working title "MTOM Inclusion Format For You (MIFFY)", a title that 
will almost surely change due to copyright issues.  The proposed 
application/soap_mtom+xml media type is thus a specific example of the 
so-called Miffy class of encodings.  We propose that a media type be 
assigned to each such use of Miffy, with application/soap_mtom+xml 
being assigned as the name for the application of Miffy to SOAP 
envelopes.

We would appreciate any input as to whether this is the most 
appropriate way to flag the use of an alternate serialisation of an XML 
format in MIME, and/or pointers to guidance on this matter.

1. http://www.w3.org/TR/soap12-mtom/
2. http://www.w3.org/TR/soap12-part0/
3. http://www.w3.org/mid/DD037726-2236-11D8-836E-00039396E15A@bea.com

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

Received on Friday, 12 December 2003 19:01:13 UTC