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

Re: Request for guidance on MIME and media types

From: Martin Duerst <duerst@w3.org>
Date: Wed, 03 Dec 2003 17:19:00 -0500
Message-Id: <>
To: Mark Nottingham <mark.nottingham@bea.com>, public-ietf-w3c@w3.org
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>

Hello Mark,

Here are my personal takes:

- public-ietf-w3c@w3.org is a coordination list, not necessarily for
   direct technical discussion. If the conclusion that you have come
   to is that you need to register a new Media Type, then I think
   you should just go forward and do that via the usual channels,
   and assure it gets reviewed e.g. on ietf-types@iana.org.

- I have read "resolve the URI to insert binary characters" below.
   This is rather worrying, because to me it sounds like "square
   circles". I have looked at the actual Miffy spec [3], and
   have seen similar confusing language. I haven't seen a worked-out
   example that would allow me to propose more precise language.

Regards,  Martin.

At 10:27 03/12/03 -0800, Mark Nottingham wrote:

>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 
>Registration of the "application/soap+xml" media type is currently under 
>way, so that SOAP envelopes 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).
>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 Wednesday, 3 December 2003 19:02:43 UTC

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