< draft-masinter-mime-web-info-01.txt   draft-masinter-mime-web-info-02.txt >
Internet Engineering Task Force L. Masinter Internet Engineering Task Force L. Masinter
Internet-Draft Adobe Internet-Draft Adobe
Intended status: Informational October 25, 2010 Intended status: Informational January 11, 2011
Expires: April 28, 2011 Expires: July 15, 2011
MIME and the Web MIME and the Web
draft-masinter-mime-web-info-01 draft-masinter-mime-web-info-02
Abstract Abstract
This document describes some of the ways in which parts of the MIME This document describes some of the ways in which parts of the MIME
system, originally designed for electronic mail, have been used in system, originally designed for electronic mail, have been used in
the Web, and some of the ways in which those uses have resulted in the Web, and some of the ways in which those uses have resulted in
difficulties. Given this background and justification, this document difficulties. Given this background and justification, this document
then goes on to outline requirements for changes to MIME registries then goes on to outline requirements for changes to MIME registries
and practices for their use within W3C and IETF, in order to address and practices for their use within W3C and IETF, in order to address
those difficulties. Within IETF, a companion Best Current Practice those difficulties. Within IETF, it is expected that a companion
document will be developed to specifically make some changes to the Best Current Practice document will make specific changes to the
Internet Media Types and Charset registries. Internet Media Types and Charset registries, among others.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on July 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Origins of MIME . . . . . . . . . . . . . . . . . . . . . 3 2.1. Origins of MIME . . . . . . . . . . . . . . . . . . . . . 3
2.2. Introducing MIME into the Web . . . . . . . . . . . . . . 4 2.2. Introducing MIME into the Web . . . . . . . . . . . . . . 4
2.3. Distributed Extensibility . . . . . . . . . . . . . . . . 5 2.3. Distributed Extensibility . . . . . . . . . . . . . . . . 5
3. Problems with application to the Web . . . . . . . . . . . . . 5 3. Problems with application to the Web . . . . . . . . . . . . . 5
3.1. Lack of clarity . . . . . . . . . . . . . . . . . . . . . 5 3.1. Lack of clarity . . . . . . . . . . . . . . . . . . . . . 5
3.2. Differences between email and Web delivery . . . . . . . . 6 3.2. Differences between email and Web delivery . . . . . . . . 6
3.3. The Rules Weren't Quite Followed . . . . . . . . . . . . . 7 3.3. The Rules Weren't Quite Followed . . . . . . . . . . . . . 7
3.4. Consequences . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Consequences . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. The Down Side of Extensibility . . . . . . . . . . . . . . 8 3.5. The Down Side of Extensibility . . . . . . . . . . . . . . 9
4. Additional considerations . . . . . . . . . . . . . . . . . . 8 4. Additional considerations . . . . . . . . . . . . . . . . . . 9
4.1. There are related problems with charsets . . . . . . . . . 8 4.1. There are related problems with charsets . . . . . . . . . 10
4.2. Embedded, downloaded, launch independent application . . . 9 4.2. Embedded, downloaded, launch independent application . . . 10
4.3. Additional Use Cases: Polyglot and Multiview . . . . . . . 9 4.3. Additional Use Cases: Polyglot and Multiview . . . . . . . 10
4.4. Evolution, Versioning, Forking . . . . . . . . . . . . . . 9 4.4. Evolution, Versioning, Forking . . . . . . . . . . . . . . 11
4.5. Content Negotiation . . . . . . . . . . . . . . . . . . . 10 4.5. Content Negotiation . . . . . . . . . . . . . . . . . . . 12
4.6. Fragment identifiers . . . . . . . . . . . . . . . . . . . 11 4.6. Fragment identifiers . . . . . . . . . . . . . . . . . . . 12
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 11 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Internet Media Type registration . . . . . . . . . . . . . 12 5.1. Internet Media Type registration . . . . . . . . . . . . . 13
5.1.1. MIME registry magic numbers for sniffing . . . . . . . 12 5.1.1. MIME registry magic numbers for sniffing . . . . . . . 13
5.1.2. Scripting and scriptable content safety . . . . . . . 12 5.1.2. Scripting and scriptable content safety . . . . . . . 13
5.1.3. Fragment identifiers . . . . . . . . . . . . . . . . . 12 5.1.3. Fragment identifiers . . . . . . . . . . . . . . . . . 13
5.1.4. Application info . . . . . . . . . . . . . . . . . . . 12 5.1.4. Application info . . . . . . . . . . . . . . . . . . . 13
5.1.5. File extensions in registry . . . . . . . . . . . . . 12 5.1.5. File extensions in registry . . . . . . . . . . . . . 14
5.2. Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Sniffing uses Media Type magic number . . . . . . . . 13 5.2.1. Sniffing uses Media Type magic number . . . . . . . . 14
5.2.2. Sniffing when there are multiple different 5.2.2. Sniffing when there are multiple different
definitions . . . . . . . . . . . . . . . . . . . . . 13 definitions . . . . . . . . . . . . . . . . . . . . . 14
5.2.3. Sniffing charsets . . . . . . . . . . . . . . . . . . 13 5.2.3. Sniffing charsets . . . . . . . . . . . . . . . . . . 14
5.2.4. Sniffing security uses scriptability info . . . . . . 13 5.2.4. Sniffing security uses scriptability info . . . . . . 14
5.3. Changes to IANA processes for MIME registries . . . . . . 13 5.3. Changes to IANA processes for MIME registries . . . . . . 15
5.4. FTP specification . . . . . . . . . . . . . . . . . . . . 13 5.4. FTP specification . . . . . . . . . . . . . . . . . . . . 15
5.5. Update some URI definitions . . . . . . . . . . . . . . . 14 5.5. Update some URI definitions . . . . . . . . . . . . . . . 15
5.6. Changes to W3C findings, processes . . . . . . . . . . . . 14 5.6. Changes to W3C findings, processes . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Informative References . . . . . . . . . . . . . . . . . . . . 14 9. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document was initially prompted by a set of discussions about This document was prompted by discussions about Web architecture and
Web architecture and the difficulties surrounding evolution of the the difficulties surrounding evolution of the Web, Internet Media
Web, Internet Media types, multiple specifications for a single media types, multiple specifications for a single media type, and related
type, and related discussions. discussions.
The document gives some of the history of MIME and its introduction The document gives some of the history of MIME and its introduction
and use in the web Section 2. It then describes some of the current and use in the Web Section 2. It then describes some of the current
difficulties with the use of MIME in the web context Section 3. This difficulties with the use of MIME in the Web context Section 3. This
background and context is then followed by a description of changes background and context is then followed by a description of changes
which would reduce some of those difficulties; the changes involve which would reduce some of those difficulties; the changes involve
specifications, practices, and registries within IETF and W3C specifications, practices, and registries within IETF and W3C
Section 5. In particular, changes to the registry and maintenance Section 5. In particular, changes to the registry and maintenance
procedures for MIME-related registries maintained by IANA are procedures for MIME-related registries maintained by IANA are
describes. describes.
Currently, discussion of this document is suggested on the mailing Currently, discussion of this document is suggested on the mailing
list www-tag@w3c.org (mailing list open for subscription to all), list www-tag@w3c.org (mailing list open for subscription to all),
archives at http://lists.w3.org/Archives/Public/www-tag/. archives at http://lists.w3.org/Archives/Public/www-tag/.
NOTE: This document is still quite rough; some of the facts need to
be checked, many sections still need expansion. Any help with
references and such appreciated.
2. History 2. History
2.1. Origins of MIME 2.1. Origins of MIME
MIME ("Multipurpose Internet Mail Extensions") was invented MIME ("Multipurpose Internet Mail Extensions") was invented
originally for email, based on general principles of "messaging" (a originally for email, based on general principles of "messaging" (a
foundational architecture framework). The role of MIME was to extend foundational architecture framework). The role of MIME was to extend
Internet email messaging from ASCII-only plain text, to include other Internet email messaging from ASCII-only plain text, to include other
character sets, images, rich documents, etc.) [RFC1521], [RFC1522]. character sets, images, rich documents, etc.) [RFC1521], [RFC1522].
The basic architecture of complex content messaging is: The basic architecture of complex content messaging is:
skipping to change at page 4, line 38 skipping to change at page 4, line 35
hypertext and the WWW folks were considering type tagging. It was hypertext and the WWW folks were considering type tagging. It was
agreed that HTTP should use MIME as the vocabulary for talking about 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 file types and character sets. The result was that HTTP 1.0 added
the "content-type" header, following (more or less) MIME. Later, for the "content-type" header, following (more or less) MIME. Later, for
content negotiation, additional uses of this technology (in 'Accept' content negotiation, additional uses of this technology (in 'Accept'
headers) were also added. headers) were also added.
The differences between the use of Internet Media Types between email The differences between the use of Internet Media Types between email
and HTTP have minor: and HTTP have minor:
o default charset: HTTP specified ISO-8859-1 as the default o default charset: HTTP originally specified ISO-8859-1 as the
character set, not US-ASCII default character set, not US-ASCII ((NEED REF TO HTTP ISSUE see
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/20; the text
that it refers to currently is here: http://greenbytes.de/tech/
webdav/draft-ietf-httpbis-p3-payload-11.html#rfc.section.2.3.1 ))
o requirement for CRLF in plain text: in practice, web clients o requirement for CRLF in plain text: in practice, Web clients
didn't restrict content to use CRLF in text/* MIME bodies. didn't restrict content to use CRLF in text/* MIME bodies.
These minor differences have caused a lot of trouble. These minor differences have caused a lot of trouble.
2.3. Distributed Extensibility 2.3. Distributed Extensibility
The real advantage of using Internet Media Types to label content The real advantage of using Internet Media Types to label content
meant that the Web was no longer restricted to a single format. This meant that the Web was no longer restricted to a single format. This
one addition meant expanding from Global Hypertext to Global one addition meant expanding from Global Hypertext to Global
Hypermedia (as suggested in a 1992 email [connolly92]) Hypermedia (as suggested in a 1992 email [connolly92])
skipping to change at page 6, line 32 skipping to change at page 6, line 32
o Some content isn't delivered over the HTTP (files on local file o Some content isn't delivered over the HTTP (files on local file
system), or there is no opportunity for tagging (data delivered system), or there is no opportunity for tagging (data delivered
over FTP) and in those cases, some other ways are needed for over FTP) and in those cases, some other ways are needed for
determining file type. determining file type.
Operating systems use (and continued to evolve) different systems to Operating systems use (and continued to evolve) different systems to
determine the 'type' of something, different from the MIME tagging determine the 'type' of something, different from the MIME tagging
and bagging: and bagging:
o 'magic numbers': in many contexts, file types could be guessed o 'magic numbers': in many contexts, file types can be guessed by
pretty reliably by looking for headers. looking for some unique string, number or pattern, which only
appears in files of that type. In circumstances where this was a
unique number, it was called a "magic number", although this
concept has been extended to other textual patterns.
o Originally MAC OS had a 4 character 'file type' and another 4 o Originally MAC OS had a 4 character 'file type' and another 4
character 'creator code' for file types. character 'creator code' for file types.
o Windows evolved to use the "file extension" -- 3 letters (and then o Windows evolved to use the "file extension" -- 3 letters (and then
more) at the end of the file name -- as the initial determination more) at the end of the file name -- as the initial determination
of the oveall type of a file. This practice has now extended to of the oveall type of a file. This practice has now extended to
other systems. other systems.
Information about these other ways of determining type (rather than Information about these other ways of determining type (rather than
skipping to change at page 7, line 12 skipping to change at page 7, line 16
unilaterally initiated (one-way) messaging, you might want to know unilaterally initiated (one-way) messaging, you might want to know
whether you could handle the data before reading it in and whether you could handle the data before reading it in and
interpreting it, but the Internet Media Types weren't enough to tell. interpreting it, but the Internet Media Types weren't enough to tell.
3.3. The Rules Weren't Quite Followed 3.3. The Rules Weren't Quite Followed
The behavior of the community when the Internet Media Type registry The behavior of the community when the Internet Media Type registry
was designed hasn't matched expectations: was designed hasn't matched expectations:
o Lots of file types aren't registered (no entry in IANA for file o Lots of file types aren't registered (no entry in IANA for file
types). types)
o Those that are, the registration is incomplete or incorrect o For many file types that are registration, the registration is
(people doing registration didn't understand 'magic number' or incomplete or incorrect (people doing registration didn't
other fields). understand 'magic number' or other fields).
o The actual content deployed or created by deployed software o The actual content deployed or created by deployed software
doesn't match the registration. doesn't match the registration.
These problems arise for various reason, for example:
o The benefit of registration to the organization that designed the
file type is unclear compared to the overhead of sheperding the
registration through the process.
o Registration requires announcing product plans in advance of
product release.
o Orgnaizations are unaware of the registration process or
misinformed.
In particular, Web implementations of Internet Media Types diverged In particular, Web implementations of Internet Media Types diverged
from expected behavior: from expected behavior:
o Browser implementors would be liberal in what they accepted, and o Browser implementors would be liberal in what they accepted, and
use what looked like a file extension in the URL and/or magic use what looked like a file extension in the URL and/or magic
number or other 'sniffing' techniques to decide file type, without number or other "sniffing" techniques to decide file type, without
assuming content-label was authoritative. This was necessary assuming content-label was authoritative. This was necessary
anyway for files that weren't delivered by HTTP. anyway for files that weren't delivered by HTTP.
o HTTP server implementors and administrators didn't supply ways of o HTTP server implementors and administrators didn't supply ways of
easily associating the 'intended' file type label with the file, easily associating the 'intended' file type label with the file,
resulting in files frequently being delivered with a label other resulting in files frequently being delivered with a label other
than the one they would have chosen if they'd thought about it, than the one they would have chosen if they'd thought about it,
and if browsers *had* assumed content-type was authoritative. and if browsers *had* assumed content-type was authoritative.
Some popular servers had default configuration files that treated Some popular servers had default configuration files that treated
any unknown type as "text/plain" (plain ext in ASCII). Since it any unknown type as "text/plain" (plain ext in ASCII). Since it
didn't matter (the browsers worked anyway), it was hard to get didn't matter (the browsers worked anyway), it was hard to get
this fixed. this fixed.
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 Incorrect senders coupled with liberal readers wind up feeding a
negative feedback loop based on the robustness principle negative feedback loop based on the robustness principle
([WikiRobust], [RFC3117]). ([WikiRobust], [RFC3117]).
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".
3.4. Consequences 3.4. Consequences
The result, alas, is that increased unreliability, in that The result, alas, is that increased unreliability, in that
o servers sending responses to browsers don't have a good guarantee o servers sending responses to browsers don't have a good guarantee
that the browser won't "sniff" the content and decide to do that the browser won't "sniff" the content and decide to do
something other than treat it as it is labeled something other than treat it as it is labeled
o browsers receiving content don't have a good guarantee that the o browsers receiving content don't have a good guarantee that the
content isn't mis-labeled content isn't mis-labeled
o intermediaries (gateways, proxies, caches, and other pieces of the o intermediaries (gateways, proxies, caches, and other pieces of the
Web infrastructure) don't have a good way of telling what the Web infrastructure) don't have a good way of telling what the
conversation means. conversation means.
This ambiguity and 'sniffing' also applies to packaged content in This ambiguity and 'sniffing' also applies to the W3C developed
webapps ('bagging' but using ZIP rather than MIME multipart). (NOTE: Widget Packaging and Configuration [Widgets] (a kind of 'bagging'
NEEDS EXPANSION, REFERENCE TO WEBAPPS) using ZIP rather than MIME multipart).
3.5. The Down Side of Extensibility 3.5. The Down Side of Extensibility
Extensibility adds great power, and allows the Web to evolve without Extensibility adds great power, and allows the Web to evolve without
committee approval of every extension. For some (those who want to committee approval of every extension. For some (those who want to
extend and their clients who want those extensions), this is power! extend and their clients who want those extensions), this is power!
For others (those who are building Web components or infrastructure), For others (those who are building Web components or infrastructure),
extensibility is a drawback -- it adds to the unreliability and extensibility is a drawback -- it adds to the unreliability and
difference of the Web experience. When senders use extensions difference of the Web experience. When senders use extensions
recipients aren't aware of, implement incorrectly or incompletely, recipients aren't aware of, implement incorrectly or incompletely,
skipping to change at page 10, line 36 skipping to change at page 11, line 49
processors ignoring version indicators encouraging content creators processors ignoring version indicators encouraging content creators
to not be careful to supply correct version indicators, leading to to not be careful to supply correct version indicators, leading to
lots of content with wrong version indicators. lots of content with wrong version indicators.
Those updating an existing Internet Media Type registration to Those updating an existing Internet Media Type registration to
account for new versions are admonished to not make previously account for new versions are admonished to not make previously
conforming documents non-conforming. This is harder to enforce than conforming documents non-conforming. This is harder to enforce than
would seem, because the previous specifications are not always would seem, because the previous specifications are not always
accurate to what the Internet Media Type was used for in practice. accurate to what the Internet Media Type was used for in practice.
(NOTE: MULTIPLE INCOMPATIBLE AUTHORITATIVE SPECS) 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'.
4.5. Content Negotiation 4.5. Content Negotiation
The general idea of content negotiation is when party A communicates 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 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 (or version, or configuration), there can be some way of allowing
some negotiation, some way for A to communication to B the available some negotiation, some way for A to communication to B the available
options, and for B to be able to accept or indicate preferences. options, and for B to be able to accept or indicate preferences.
Content negotiation happens all over. When one fax machine twirps to Content negotiation happens all over. When one fax machine twirps to
skipping to change at page 12, line 36 skipping to change at page 13, line 50
5.1.3. Fragment identifiers 5.1.3. Fragment identifiers
Problem: MIME type definitions don't talk about fragment identifiers. Problem: MIME type definitions don't talk about fragment identifiers.
require definition of fragment identifier applicability; add fragID require definition of fragment identifier applicability; add fragID
semantics semantics
5.1.4. Application info 5.1.4. Application info
Problem: ((hasn't been expanded) 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 Could the 'applications that use this type' section to be clearer
about whether the file type is frequently for embedding (plug-in) or about whether the media type is intended to be piece of self-
as a separate document with auto-launch (MIME handler), or should contained content (it is sensible to store the MIME data as a file
always be downloaded? Is there a separate issue for 'auto-play on and later launch a separate application to view or interact with it)
download' vs. 'ask user for permission'? 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.
5.1.5. File extensions in registry 5.1.5. File extensions in registry
Problem: Sniffing needs to use file extensions too; signify which Problem: Sniffing needs to use file extensions too; signify which
file extensions are useful for sniffing. file extensions are useful for sniffing.
Be clearer about file extension use and relationship of file Be clearer about file extension use and relationship of file
extensions to MIME handlers extensions to MIME handlers
5.2. Sniffing 5.2. Sniffing
Various new specifications discuss, promote or mandate the use of Various new specifications discuss, promote or mandate the use of
'sniffing' -- using the content of the data to supplement or even 'sniffing' -- using the content of the data to supplement or even
override the declared content-type or charset. Update these override the declared content-type or charset. Update these
specifications. specifications.
5.2.1. Sniffing uses Media Type magic number 5.2.1. Sniffing uses Media Type magic number
Update the proposed Media Type sniffing document so that sniffing Update the proposed Media Type sniffing document ([mime-sniff]) so
uses MIME registry for 'magic numbers'. that sniffing uses MIME registry for 'magic numbers.
5.2.2. Sniffing when there are multiple different definitions 5.2.2. Sniffing when there are multiple different definitions
Address issue of sniffing when there are multiple independent Address issue of sniffing when there are multiple independent
definitions of the same MIME type. definitions of the same MIME type.
5.2.3. Sniffing charsets 5.2.3. Sniffing charsets
Update sniffing of charsets to use charset reference info. Update sniffing of charsets in HTML5 ([HTML5-charset] to use the
charset reference info.
5.2.4. Sniffing security uses scriptability info 5.2.4. Sniffing security uses scriptability info
If the Internet Media Type registry is more explicit about which If the Internet Media Type registry is more explicit about which
kinds of content contain what kind of scriptability access, then the kinds of content contain what kind of scriptability access, then the
specifications for sniffing can reference the Internet Media Type specifications for sniffing can reference the Internet Media Type
registry to determine what kinds of sniffing constitute a 'privelege registry to determine what kinds of sniffing constitute a 'privelege
upgrade'. upgrade'.
Note that all sniffing can be a priviledge upgrade, if there is a Note that all sniffing can be a priviledge upgrade, if there is a
skipping to change at page 14, line 19 skipping to change at page 15, line 40
definitions. definitions.
5.6. Changes to W3C findings, processes 5.6. Changes to W3C findings, processes
Update Tag finding on authoritative metadata: is it possible to Update Tag finding on authoritative metadata: is it possible to
remove 'authority'? remove 'authority'?
new: MIME and Internet Media Type section to WebArch, referencing new: MIME and Internet Media Type section to WebArch, referencing
this memo this memo
New: Add a W3C Web architecture material on MIME in HTML to W3C web New: Add a W3C Web architecture material on MIME in HTML to W3C site,
site, referencing this memo referencing this memo
Reconsider other extensibility mechanisms (namespaces, for example): Reconsider other extensibility mechanisms (namespaces, for example):
should they use MIME or something like it? should they use MIME or something like it?
6. Acknowledgements 6. Acknowledgements
This document is the result of discussions among many individuals in This document is the result of discussions among many individuals in
the IETF and W3C. Special thanks to Noah Mendelsohn. the IETF and W3C. Special thanks to Alexey Melnikov, Noah Mendelsohn.
7. IANA Considerations 7. IANA Considerations
This document includes no specific changes to IANA registries or This document includes no specific changes to IANA registries or
processes. However, it outlines several considerations for future processes. However, it outlines several considerations for future
explicit recommendations to IANA, to change Internet Media Type and explicit recommendations to IANA, to change Internet Media Type and
Charset registries and the processes around their maintenance. IANA Charset registries and the processes around their maintenance. IANA
evaluation of the feasibility of these changed processes is required. evaluation of the feasibility of these changed processes is required.
8. Security Considerations 8. Security Considerations
This document discusses some of the security issues resulting from This document discusses some of the security issues resulting from
use (and mis-use) of MIME content types in the Web. use (and mis-use) of MIME content types in the Web.
9. Informative References 9. Informative References
[HTML5-charset]
Hickson, I., "HTML5: A vocabulary and associated APIs for
HTML and XHTML (8.2.2.1 Determining the character
encoding)", <http://www.w3.org/TR/html5/
parsing.html#determining-the-character-encoding>.
[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", Describing the Format of Internet Message Bodies",
RFC 1521, <http://tools.ietf.org/html/rfc5521>. RFC 1521, <http://tools.ietf.org/html/rfc5521>.
[RFC1522] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC1522] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Two: Message Header Extensions for Non-ASCII Text", Part Two: Message Header Extensions for Non-ASCII Text",
RFC 1522, September 1993, RFC 1522, September 1993,
<http://tools.ietf.org/html/rfc1522>. <http://tools.ietf.org/html/rfc1522>.
skipping to change at page 15, line 22 skipping to change at page 16, line 48
<http://tools.ietf.org/rfc/rf1945>. <http://tools.ietf.org/rfc/rf1945>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996, <http://tools.ietf.org/html/rfc2046>. November 1996, <http://tools.ietf.org/html/rfc2046>.
[RFC3117] Rose, M., "On the Design of Application Protocols", [RFC3117] Rose, M., "On the Design of Application Protocols",
RFC 3117, November 2001, RFC 3117, November 2001,
<http://tools.ietf.org/html/rfc3117>. <http://tools.ietf.org/html/rfc3117>.
[Widgets] Caceres, M., "Widget Packaging and Configuration",
<http://www.w3.org/TR/widgets/>.
[WikiRobust] [WikiRobust]
"Robustness principle", 2010, "Robustness principle", 2010,
<http://en.wikipedia.org/wiki/Robustness_principle>. <http://en.wikipedia.org/wiki/Robustness_principle>.
[connolly92] [connolly92]
Connolly, D., "Global Hypermedia", Oct 1992, <http:// Connolly, D., "Global Hypermedia", Oct 1992, <http://
lists.w3.org/Archives/Public/www-talk/1992SepOct/ lists.w3.org/Archives/Public/www-talk/1992SepOct/
0024.html>. 0024.html>.
[mime-sniff] [mime-sniff]
Barth, A. and I. Hickson, "Media Type Sniffing", May 2010, Barth, A. and I. Hickson, "Media Type Sniffing",
<http://tools.ietf.org/html/draft-abarth-mime-sniff>. December 2010,
<http://tools.ietf.org/html/draft-ietf-websec-mime-sniff>.
Author's Address Author's Address
Larry Masinter Larry Masinter
Adobe Adobe
345 Park Ave. 345 Park Ave.
San Jose, 95110 San Jose, 95110
USA USA
Phone: +1 408 536 3024 Phone: +1 408 536 3024
 End of changes. 30 change blocks. 
75 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35