Re: Request for guidance on MIME and media types

Hello Mark,

Here are my personal takes:

- [email protected] 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 [email protected].

- 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 
>serialisation.
>
>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/[email protected]
>
>--
>Mark Nottingham   Principal Technologist
>Office of the CTO   BEA Systems