December 2003 - Ietf-types

Request for guidance on MIME and media types
by Mark Nottingham 28 Dec '03

28 Dec '03

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(a)example.org>" --MIME_boundary Content-Type: application/soap_mtom+xml Content-Transfer-Encoding: 8bit Content-ID: <envelope01(a)example.org> <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="..."> <SOAP-ENV:Body>  <Image type="image/jpeg"><Include xmlns="..." href="cid:binary01@example.org"/></Image>  </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <binary01(a)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>  <Image type="image/jpeg">[base64-encoded image]</Image>  </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

2 1

RE: Proposed Registration of MIME media type application/vnd.wordperfect
by Kim Scarborough 21 Dec '03

21 Dec '03

> What is the relationship of this to > http://www.iana.org/assignments/media-types/application/wordperfect5.1 > ? Well, the problem with that was that they appended the version string on the end of the name, so nobody uses it anymore (WordPerfect is up to version 11 now--5.1 was only for DOS and Unix CLI). It's too bad it was registered that way, but it's too late now, so I figured I'd submit this. Also, RFC 2048 encourages re-registering grandfathered media types, so what the heck. -- ------------------------------------------------------------------------------- Kim Scarborough http://www.unknown.nu/kim/ -------------------------------------------------------------------------------

1 0

Proposed Registration of MIME media type application/vnd.wordperfect
by Kim Scarborough 21 Dec '03

21 Dec '03

MIME media type name: application MIME subtype name: vnd.wordperfect Required parameters: none Optional parameters: none Encoding Considerations: Wordperfect files are binary data and should be suitably encoded for protocols that do not handle binary data. Security Considerations: The security issues associated with this type have not been assessed. Interoperability considerations: As this is not an open standard, interoperability is left up to the discretion of the developer (currently Corel Corp.). Published specification: none Applications which use this media type: The WordPerfect suite of office applications. Additional information: Magic number(s): none File extension: .wpd Macintosh File Type Code(s): "WPC2" Person & email address to contact for further information: Questions about this proposal should be directed to Kim Scarborough <user(a)unknown.nu>. Intended usage: COMMON Author/Change controller: Corel Corporation 1600 Carling Avenue Ottawa, Ontario Canada K1Z 8R7

2 1

proposed media type registration: application/voicexml+xml
by Max Froumentin 20 Dec '03

20 Dec '03

Hi, Please consider the attached Internet Draft submission: "The application/voicexml+xml Media Type" (originating from the Voice Browser Working Group of the W3C), for review. Cheers, Max Froumentin, W3C

6 14

please review 'application/pdf'
by Larry Masinter 17 Dec '03

17 Dec '03

http://www.ietf.org/internet-drafts/draft-zilles-pdf-00.txt This draft updates the (9-year-old) application/pdf registration.

7 23

RE: proposed media type registration: application/voicexml+xml
by Francois Yergeau 16 Dec '03

16 Dec '03

Seconded, for all the reasons given by Martin. Please restore the charset parameter. Regards, -- François > -----Message d'origine----- > De : Martin Duerst [mailto:duerst@w3.org] > Envoyé : 16 décembre 2003 16:33 > À : Max Froumentin; ietf-types(a)iana.org > Cc : w3c-archive(a)w3.org; ietf-xml-mime(a)imc.org; Ben Kovitz; Linus > Walleij > Objet : Re: proposed media type registration: application/voicexml+xml > > > > Hello Max, others, > > I just by chance realized that you had removed the 'charset' > parameter from the registration for application/voicexml+xml, > and also for application/ssml+xml. I have found something similar > in other recent registration proposals. > > Here is why I think this is really not a good idea: > > First, we start to get into a patchwork where some types > allow the 'charset', and others don't. Assuming that there > is something like generic XML processors (e.g. parsers) > (which is the whole point of XML), how should such a parser > know whether the 'charset' parameter is allowed or not, > and keep up with new registrations? > > Second, there are various scenarios a charset parameter in > the header is automatically generated, or where it's much > easier to generate it than to avoid it. The following are > examples: > - The classical example of transcoding (converting from one > encoding to another). Not very frequent these days on the > Web in general, but still used for Russian/Cyrillic encodings > and in some mobile phone scenarios. > - Scripting technologies, for example JSP. With JSP, it is much > more straightforward to produce output with the right encoding > with a 'charset' parameter in the header than without. The > reason for this is that JSP allows to produce any kind of > output, not limited to XML, and has to know how to convert > from the Java-internal encoding to whatever is used on the > wire. Putting that information in the 'charset' parameter > in the header then is straightforward; anything else has > to be done by hand. Hopefully, excluding certain classes > of content production technologies is not what you want. > - Databases that store content as characters rather than bytes, > in a single encoding (in many cases e.g. uniformly UTF-8), > and transcode on output. Again, if they use generic technology, > getting the 'charset' into the header is much more straightforward > than putting it into the body. > > Given all these cases, I think it's not at all appropriate to > remove the 'charset' parameter from the registration, because > it would severely limit the use of technology that in good > faith, and with good reasons, is using it. > > In the long run, I think that an update to RFC 3023 should address > these issues in more detail to help content producers understand the > advantages and problems related to charset/encoding information. > > Regards, Martin. > > > At 17:15 03/08/21 +0200, Max Froumentin wrote: > > >Hi, > > > >Please consider the attached Internet Draft submission: "The > >application/voicexml+xml Media Type" (originating from the Voice > >Browser Working Group of the W3C), for review. > > > >Cheers, > > > >Max Froumentin, W3C >

1 0

Registration of MIME media type Application/EDI-Tradacoms
by Kyle Meadors 06 Dec '03

06 Dec '03

MIME media type name: Application MIME subtype name: IETF Tree - EDI-Tradacoms Required parameters: None Optional parameters: CHARSET, as defined for MIME Encoding considerations: May need BASE64 or QUOTED-PRINTABLE transfer encoding on transports not capable of handling 8 BIT text Security considerations: Refer to RFC 1767 Section 7 Interoperability considerations: None Published specification: Refer to RFC 1767 Applications which use this media type: EDI, EDIINT Additional information: Magic number(s): none File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: Name: Kyle Meadors Email: kyle(a)drummondgroup.com Intended usage: COMMON. UK EDI standard to support EDIINT AS2 in UK Author/Change controller: Drummond Group Inc.

3 2