Request for guidance on MIME and media types
Mark Nottingham
mark.nottingham at bea.com
Sat Dec 13 01:01:14 CET 2003
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 at example.org>"
--MIME_boundary
Content-Type: application/soap_mtom+xml
Content-Transfer-Encoding: 8bit
Content-ID: <envelope01 at 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 at 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 at 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
More information about the Ietf-types
mailing list