This document describes some of the ways in which parts of the MIME system, originally designed for electronic mail, have been used in the Web, and some of the ways in which those uses have resulted in difficulties. Given this background and justification, this document then goes on to outline requirements for changes to MIME registries and practices for their use within W3C and IETF, in order to address those difficulties. Within IETF, it is expected that a companion Best Current Practice document will make specific changes to the Internet Media Types and Charset registries, among others.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on July 15, 2011.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
2.1. Origins of MIME
2.2. Introducing MIME into the Web
2.3. Distributed Extensibility
3. Problems with application to the Web
3.1. Lack of clarity
3.2. Differences between email and Web delivery
3.3. The Rules Weren't Quite Followed
3.5. The Down Side of Extensibility
4. Additional considerations
4.1. There are related problems with charsets
4.2. Embedded, downloaded, launch independent application
4.3. Additional Use Cases: Polyglot and Multiview
4.4. Evolution, Versioning, Forking
4.5. Content Negotiation
4.6. Fragment identifiers
5.1. Internet Media Type registration
5.1.1. MIME registry magic numbers for sniffing
5.1.2. Scripting and scriptable content safety
5.1.3. Fragment identifiers
5.1.4. Application info
5.1.5. File extensions in registry
5.2.1. Sniffing uses Media Type magic number
5.2.2. Sniffing when there are multiple different definitions
5.2.3. Sniffing charsets
5.2.4. Sniffing security uses scriptability info
5.3. Changes to IANA processes for MIME registries
5.4. FTP specification
5.5. Update some URI definitions
5.6. Changes to W3C findings, processes
7. IANA Considerations
8. Security Considerations
9. Informative References
§ Author's Address
This document was prompted by discussions about Web architecture and the difficulties surrounding evolution of the Web, Internet Media types, multiple specifications for a single media type, and related discussions.
The document gives some of the history of MIME and its introduction and use in the Web Section 2 (History). It then describes some of the current difficulties with the use of MIME in the Web context Section 3 (Problems with application to the Web). This background and context is then followed by a description of changes which would reduce some of those difficulties; the changes involve specifications, practices, and registries within IETF and W3C Section 5 (Recommendations). In particular, changes to the registry and maintenance procedures for MIME-related registries maintained by IANA are describes.
Currently, discussion of this document is suggested on the mailing list email@example.com (mailing list open for subscription to all), archives at http://lists.w3.org/Archives/Public/www-tag/.
MIME ("Multipurpose Internet Mail Extensions") was invented originally for email, based on general principles of "messaging" (a foundational architecture framework). The role of MIME was to extend Internet email messaging from ASCII-only plain text, to include other character sets, images, rich documents, etc.) [RFC1521] (Borenstein, N. and N. Freed, “MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies,” .), [RFC1522] (Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text,” September 1993.). The basic architecture of complex content messaging is:
MIME is a "tagging and bagging" specification:
- How to label content so the intent of how the content should be interpreted is known.
- How to wrap the content so the label is clear, or, if there are multiple parts to a single message, how to combine them.
"MIME types" (renamed "Internet Media Types" in later specs [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.)) are part of the "tagging" -- a way to describe the content of a message so that it could be used to initiate interpretation of a message. The "Internet Media Type registry" (MIME type registry) is where someone can tell the world what a particular label means, as far as the sender's intent of how recipients should process a message of that type, and the description of a recipients capability and ability for senders.
The original World Wide Web (the 0.9 version of HTTP, see [RFC1945] (Berners-Lee, T., Fielding, R., and H. Nielsen, “Hypertext Transfer Protocol -- HTTP/1.0,” May 1996.)) didn't have "tagging and bagging" -- everything sent via HTTP was assumed to be HTML. However, at the time (early 1990's) other distributed information access systems, including Gopher (distributed menu system) and WAIS (remote access to document databases) were adding capabilities for accessing many things other text and hypertext and the WWW folks were considering type tagging. It was agreed that HTTP should use MIME as the vocabulary for talking about file types and character sets. The result was that HTTP 1.0 added the "content-type" header, following (more or less) MIME. Later, for content negotiation, additional uses of this technology (in 'Accept' headers) were also added.
The differences between the use of Internet Media Types between email and HTTP have minor:
These minor differences have caused a lot of trouble.
The real advantage of using Internet Media Types to label content meant that the Web was no longer restricted to a single format. This one addition meant expanding from Global Hypertext to Global Hypermedia (as suggested in a 1992 email (Connolly, D., “Global Hypermedia,” Oct 1992.) [connolly92])
|The Internet currently serves as the backbone for a global hypertext. FTP and email provided a good start, and the gopher, WWW, or WAIS clients and servers make wide area information browsing simple. These systems even interoperate, with email servers talking to FTP servers, WWW clients talking to gopher servers, on and on.|
|This currently works quite well for text. But what should WWW clients do as Gopher and WAIS servers begin to serve up pictures, sounds, movies, spreadsheet templates, postscript files, etc.? It would be a shame for each to adopt its own multimedia typing system.|
|If they all adopt the MIME typing system (and as many other features from MIME as are appropriate), we can step from global hypertext to global hypermedia that much easier.|
The fact that HTTP could reliably transport images of different formats, for example, allowed NCSA to add <img> to HTML. MIME allowed other document formats (Word, PDF, Postscript) and other kinds of hypermedia, as well as other applications, to be part of the Web. MIME was arguably the most important extensibility mechanism in the Web.
Unfortunately, while the use of Internet Media Types for the Web added incredible power, a number of problems have arisen.
Many people are confused about the purpose of MIME in the Web, its uses, the meaning of Internet Media Types. Many W3C specifications TAG findings and Internet Media Type registrations make what are incorrect assumptions about the meaning and purposes of a Internet Media Type registration.
Some of the differences between the application contexts of email and Web delivery determine different requirements:
Operating systems use (and continued to evolve) different systems to determine the 'type' of something, different from the MIME tagging and bagging:
Information about these other ways of determining type (rather than by the content-type label) were gathered for the Internet Media Type registry; those registering types are encouraged to also describe 'magic numbers', Mac file type, common file extensions. However, since there was no formal use of that information, the quality of that information in the registry is haphazard.
Finally, there was the fact that tagging and bagging might be OK for unilaterally initiated (one-way) messaging, you might want to know whether you could handle the data before reading it in and interpreting it, but the Internet Media Types weren't enough to tell.
The behavior of the community when the Internet Media Type registry was designed hasn't matched expectations:
These problems arise for various reason, for example:
In particular, Web implementations of Internet Media Types diverged from expected behavior:
Thus, in many situations, because of poor control over server administration or weak file-type detection in popular web server technology, receivers might find that 'magic number' scanning was more reliable than the actual labeled content-type.
Incorrect senders coupled with liberal readers wind up feeding a negative feedback loop based on the robustness principle ([WikiRobust] (, “Robustness principle,” 2010.), [RFC3117] (Rose, M., “On the Design of Application Protocols,” November 2001.)).
In addition, since the "magic number" technology is heuristic, it is possible to have different formats all with the same "magic number" or more generally, more than one different format that might be reasonably "sniffed".
For example, there are cases where the reuse of one file type's magic number for another file type is intentional -- deliberate "puns", attempts to usurp ownership of another vendor, group, or standards organization's control over a file format, for example.
Secondly, there are cases where a single file might match more than one 'magic number' or recognition pattern, and different recievers apply heuristics differently.
Finally, there are simple cases where the labeled type (text/plain, application/octet-stream) is more general and could reasonably be used with content which might otherwise match other patterns.
For example, the sniffing that's done by some web browsers text/plain. If you serve it the perfectly valid text file with the content:
<?xml version="1.0"?> <animals> <dog>Rufus</fish> <cat>Kitty</elephant> </animals>
the browser will not display it (there are intentionally mismatched tags on the 3rd line). Something like this might come up, for example, if you had a bug database, with links to the text of documents that caused problems. This buggy XML, served as text/plain, should render, but it does not in browsers that incorrectly guess "application/xml".
The "<?xml" is treated as a "magic number", and the wrong thing is happening. The browser thinks "surely it's XML"; the bug tracking app knows "on the contrary, I'm serving it as text precisely because I know it's not".
The result, alas, is that increased unreliability, in that
This ambiguity and 'sniffing' also applies to the W3C developed Widget Packaging and Configuration [Widgets] (Cáceres, M., “Widget Packaging and Configuration,” .) (a kind of 'bagging' using ZIP rather than MIME multipart).
Extensibility adds great power, and allows the Web to evolve without committee approval of every extension. For some (those who want to extend and their clients who want those extensions), this is power! For others (those who are building Web components or infrastructure), extensibility is a drawback -- it adds to the unreliability and difference of the Web experience. When senders use extensions recipients aren't aware of, implement incorrectly or incompletely, then communication often fails. With messaging, this is a serious problem, although most 'rich text' documents are still delivered in multiple forms (using multipart/alternative).
If your job is to support users of a popular browser, however, where each user has installed a different configuration of file handlers and extensibility mechanisms, MIME may appear to add unnecessary complexity and variable experience for users of all but the most popular types.
This section notes some additional considerations.
MIME includes provisions not only for file 'types', but also, importantly the "character encoding" used by text types: for example, simple US ASCII, Western European ISO-8859-1, Unicode UTF8. A similar vicious cycle also happened with character set labels: mislabeled content happily processed correctly by liberal browsers encouraged more and more sites to proliferate text with mis-labeled character sets, to the point where browsers feel they *have* to guess the wrong label. (NEEDS EXPANSION)
There are sites that intentionally label content as iso-2022-jp or euc-jp when it is in fact one of the Microsoft extension charsets (e.g., for access to circled digits. This is an intentional misuse of the definitions of the charsets themselves -- definitions which originated at the national standards body level.
The type of a document might be determined not only for entire documents "HTML" vs "Word" vs "PDF", but also to embedded components of documents, "JPEG image" vs. "PNG image". However, the use cases, requirements and likely operational impact of MIME handling is likely different for those use cases.
There are some interesting additional use cases which add to the design requirements:
The subject of format/language/type evolution is complex; this section is a litle terse.
Formats and their specifications evolve over time. There are several reasons for the evolution: innovation, compatibility with other implementations, attempts to gain control.
Some times new evolutions are "compatible", although compatibility has several variations. It is part of the responsibility of the designer of a new version of a file type to try to insure both forward and backward compatibility: new documents work reasonably (with some fallback) with old viewers and that old documents work reasonably with new viewers. In some cases this is accomplished, others not; in some cases, "works reasonably" is softened to "either works reasonably or gives clear warning about nature of problem (version mismatch)."
In MIME, the 'tag', the Internet Media Type, corresponds to the versioned series. Internet Media Types do not identify a particular version of a file format. Rather, the general idea is that the Internet Media Type identifies the family, and also how you're supposed to otherwise find version information on a per-format basis. Many (most) file formats have an internal version indicator, with the idea that you only need a new Internet Media Type to designate a completely incompatible format. The notion of an "Internet Media Type" is very course-grained. The general approach to this has been that the actual Media Type includes provisions for version indicator(s) embedded in the content itself to determine more precisely the nature of how the data is to be interpreted. That is, the message itself contains further information.
Unfortunately, lots has gone wrong in this scenario as well -- processors ignoring version indicators encouraging content creators to not be careful to supply correct version indicators, leading to lots of content with wrong version indicators.
Those updating an existing Internet Media Type registration to account for new versions are admonished to not make previously conforming documents non-conforming. This is harder to enforce than would seem, because the previous specifications are not always accurate to what the Internet Media Type was used for in practice.
In addition, there are situations where there are simultaneously multiple, different specifications which all claim to authoritatively define the same internet media type; one might be couched as 'newer' or 'better', or the specifications might be 'forked'.
The general idea of content negotiation is when party A communicates to party B, and the message can be delivered in more than one format (or version, or configuration), there can be some way of allowing some negotiation, some way for A to communication to B the available options, and for B to be able to accept or indicate preferences.
Content negotiation happens all over. When one fax machine twirps to another when initially connecting, they are negotiating resolution, compression methods and so forth. In Internet mail, which is a one-way communication, the "negotiation" consists of the sender preparing and sending multiple versions of the message, one in text/html, one in text/plain, for example, in sender-preference order. The recipient then chooses the first version it can understand.
HTTP added "Accept" and "Accept-language" to allow content negotiation in HTTP GET, based on Internet Media Types, and there are other methods explained in the HTTP spec.
The Web added the notion of being able to address part of a content and not the whole content by adding a 'fragment identifier' to the URL that addressed the data. Of course, this originally made sense for the original Web with just HTML, but how would it apply to other content. The URL spec glibly noted that "the definition of the fragment identifier meaning depends on the Internet Media Type", but unfortunately, few of the Internet Media Type definitions included this information, and practices diverged greatly.
If the interpretation of fragment identifiers depends on the MIME type, though, this really crimps the style of using fragment identifiers differently if content negotiation is wanted.
This section outlines the kinds of changes needed to bring the MIME system in line with current practice and to address the problems outlined above. The purpose of this text is not to specify the exact details of how changes can be accomplished, but rather to find broad aggreement.
We need a clear direction on how to make the Web more reliable, not less. We need a realistic transition plan from the unreliable Web to the more reliable one. Part of this is to encourage senders (Web servers) to mean what they say, and encourage recipients (browsers) to give preference to what the senders are sending.
We should try to create specifications for protocols and best practices that will lead the Web to more reliable and secure communication. To this end, we give an overall architectural approach to use of MIME, and then specific specifications, for HTTP clients and servers, Web Browsers in general, proxies and intermediaries, which encourage behavior which, on the one hand, continues to work with the already deployed infrastructure (of servers, browsers, and intermediaries), but which advice, if followed, also improves the operability, reliability and security of the Web.
This section outlines requirements for standards and practices intended to address some of the difficulties. This is an early version, which mainly contains "strawman" proposals for changes. It is intended to stimulate discussion -- however, the hope is that we can get agreement about the nature of the problems and current situation before focusing in detail about possible solutions. However, having at least strawman proposals seems to be helpful. For some problems, additional changes to IETF and W3C specifications are also be advisable; the expectations are briefly outlined here.
Update the Internet Media Type registry and registration process.
Be clearer about relationship of 'magic numbers' to sniffing; review Internet Media Types already registered and update.
Be clearer about requiring Security Considerations to address risks of sniffing
Problem: MIME type definitions don't talk about fragment identifiers.
require definition of fragment identifier applicability; add fragID semantics
Problem: Most often, the original conception of MIME for email "attachments" was that each content body was really a separate communication; however some Internet Media Types do not have that characteristic.
Could the 'applications that use this type' section to be clearer about whether the media type is intended to be piece of self-contained content (it is sensible to store the MIME data as a file and later launch a separate application to view or interact with it) or whether it is (always, most often, not really appropriate) to do so, and instead this content is intended or embedding or processing as a part of a larger context or application. Of course there may be situations where either holds with the same media type.
Problem: Sniffing needs to use file extensions too; signify which file extensions are useful for sniffing.
Be clearer about file extension use and relationship of file extensions to MIME handlers
Various new specifications discuss, promote or mandate the use of 'sniffing' -- using the content of the data to supplement or even override the declared content-type or charset. Update these specifications.
Update the proposed Media Type sniffing document ([mime‑sniff] (Barth, A. and I. Hickson, “Media Type Sniffing,” December 2010.)) so that sniffing uses MIME registry for 'magic numbers.
Address issue of sniffing when there are multiple independent definitions of the same MIME type.
Update sniffing of charsets in HTML5 ([HTML5‑charset] (Hickson, I., “HTML5: A vocabulary and associated APIs for HTML and XHTML (22.214.171.124 Determining the character encoding),” .) to use the charset reference info.
If the Internet Media Type registry is more explicit about which kinds of content contain what kind of scriptability access, then the specifications for sniffing can reference the Internet Media Type registry to determine what kinds of sniffing constitute a 'privelege upgrade'.
Note that all sniffing can be a priviledge upgrade, if there is a buggy recipient, although bugs can be fixed, but spec violations are a problem.
Problem: Internet Media Type registries are hard to update, and there can be different definitions of the same MIME type.
STRAWMAN: Allow commenting or easier update; not all Internet Media Type owners need or have all the information the internet needs. Wiki for Internet Media Types as well as formal registry? Ability to add comments about deployed senders, deployed content, deployed recievers.
Do FTP clients also change rules about guessing file types based on OS of FTP server?
ftp, file, need sniffing, http sometimes does; data defaults to text/plain rather than sniffing. Should this info be in the URI definitions.
Update Tag finding on authoritative metadata: is it possible to remove 'authority'?
new: MIME and Internet Media Type section to WebArch, referencing this memo
New: Add a W3C Web architecture material on MIME in HTML to W3C site, referencing this memo
Reconsider other extensibility mechanisms (namespaces, for example): should they use MIME or something like it?
This document is the result of discussions among many individuals in the IETF and W3C. Special thanks to Alexey Melnikov, Noah Mendelsohn.
This document includes no specific changes to IANA registries or processes. However, it outlines several considerations for future explicit recommendations to IANA, to change Internet Media Type and Charset registries and the processes around their maintenance. IANA evaluation of the feasibility of these changed processes is required.
This document discusses some of the security issues resulting from use (and mis-use) of MIME content types in the Web.
|[HTML5-charset]||Hickson, I., “HTML5: A vocabulary and associated APIs for HTML and XHTML (126.96.36.199 Determining the character encoding).”|
|[RFC1521]||Borenstein, N. and N. Freed, “MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies,” RFC 1521.|
|[RFC1522]||Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text,” RFC 1522, September 1993.|
|[RFC1945]||Berners-Lee, T., Fielding, R., and H. Nielsen, “Hypertext Transfer Protocol -- HTTP/1.0,” RFC 1945, May 1996.|
|[RFC2046]||Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” RFC 2046, November 1996.|
|[RFC3117]||Rose, M., “On the Design of Application Protocols,” RFC 3117, November 2001.|
|[Widgets]||Cáceres, M., “Widget Packaging and Configuration.”|
|[WikiRobust]||“Robustness principle,” 2010.|
|[connolly92]||Connolly, D., “Global Hypermedia,” Oct 1992.|
|[mime-sniff]||Barth, A. and I. Hickson, “Media Type Sniffing,” December 2010.|
|345 Park Ave.|
|San Jose, 95110|
|Phone:||+1 408 536 3024|