draft-seantek-windows-image-02.txt   rfc7903.txt 
Network Working Group S. Leonard Independent Submission S. Leonard
Internet-Draft Penango, Inc. Request for Comments: 7903 Penango, Inc.
Intended Status: Informational March 6, 2016 Category: Informational September 2016
Expires: September 7, 2016 ISSN: 2070-1721
Windows Image Media Types Windows Image Media Types
draft-seantek-windows-image-02
Abstract Abstract
This document registers media types for certain image formats This document registers media types for certain image formats
promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, promulgated in Microsoft Windows, namely image/wmf, image/x-wmf,
image/emf, image/x-emf, and image/bmp for use with Windows Metafile, image/emf, image/x-emf, and image/bmp for use with Windows Metafile,
Enhanced Metafile, and Windows Bitmap formats. Originally designed Enhanced Metafile, and Windows Bitmap formats. Originally designed
for Microsoft Windows 2.0 and 3.0, these image files are intended to for Microsoft Windows 2.0 and 3.0, these image files are intended to
be portable between applications and devices, and may contain both be portable between applications and devices, and they may contain
vector and raster graphics. both vector and raster graphics.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This is a contribution to the RFC Series, independently of any other
Task Force (IETF). Note that other groups may also distribute RFC stream. The RFC Editor has chosen to publish this document at
working documents as Internet-Drafts. The list of current Internet- its discretion and makes no statement about its value for
Drafts is at http://datatracker.ietf.org/drafts/current/. implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7903.
material or to cite them other than as "work in progress."
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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.
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.
1. Introduction Table of Contents
1.1. Windows Metafiles 1. Introduction ....................................................2
1.1. Windows Metafiles ..........................................2
1.2. Windows Bitmaps ............................................3
2. Windows Metafile Media Type Registration Application ............4
3. Enhanced Metafile Media Type Registration Application ...........6
4. Windows Bitmap Media Type Registration Application ..............9
5. IANA Considerations ............................................11
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
Author's Address ..................................................12
1. Introduction
1.1. Windows Metafiles
Long before the invention of Scalable Vector Graphics, Microsoft Long before the invention of Scalable Vector Graphics, Microsoft
Corporation recognized the value of recording images in a format that Corporation recognized the value of recording images in a format that
its applications and operating systems could easily render its applications and operating systems could easily render
irrespective of the output device. With the release of Windows 3.0, irrespective of the output device. With the release of Windows 3.0,
Microsoft released its Windows Metafile (WMF) format, which can Microsoft released its Windows Metafile (WMF) format, which can
contain vector and raster graphics in one package. As a binary format contain vector and raster graphics in one package. As a binary
that needed to work on 16-bit machines, WMF is comprised of a format that needed to work on 16-bit machines, WMF is comprised of a
sequence of record structures. Each record contains drawing commands, sequence of record structures. Each record contains drawing
object definitions, and configuration settings. When a metafile is commands, object definitions, and configuration settings. When a
processed, the image can be rendered on a display, output to a metafile is processed, the image can be rendered on a display, output
printer or plotter, stored in memory, or saved to some persistent to a printer or plotter, stored in memory, or saved to some
storage. Reflecting the relationship to the Windows Graphics Device persistent storage. Reflecting the relationship to the Windows
Interface (GDI) API, WMF metafiles are "played" to a playback device Graphics Device Interface (GDI) API, WMF data is "played" to a
context in the same manner that PostScript content is treated as an playback device context in the same manner that PostScript content is
executable program that results in the output of the original treated as an executable program that results in the output of the
document. original document.
As Microsoft's first 32-bit operating system, Windows NT 3.1 As Microsoft's first 32-bit operating system, Windows NT 3.1
introduced an overhaul to the Windows API ("Win32") and the in-memory introduced an overhaul to the Windows API ("Win32") and the in-memory
formats upon which those APIs relied. The Enhanced Metafile (EMF) formats upon which those APIs relied. The Enhanced Metafile (EMF)
format was created at this time, using 32-bit values instead of WMF's format was created at this time, using 32-bit values instead of WMF's
16-bit values. In Windows XP, Microsoft extended EMF with "EMF+", 16-bit values. In Windows XP, Microsoft extended EMF with "EMF+",
adding support for Windows GDI+. adding support for Windows GDI+.
Many implementations of WMF and EMF were created because of Windows' Many implementations of WMF and EMF were created because of Windows'
commercial success in the 1990s. A large body of free and commercial success in the 1990s. A large body of free and
commercially available clip art and other artwork exists in this commercially available clip art and other artwork exists in this
format. Furthermore, WMF content appears non-normatively in certain format. Furthermore, WMF content appears non-normatively in certain
standards (e.g., [OOXML]); the usage is common enough that an standards (e.g., [OOXML]); the usage is common enough that an
implementer would almost certainly need to support it for basic implementer would almost certainly need to support it for basic
interoperability. interoperability.
Microsoft publicly documented the WMF format as early as the 1992 Microsoft publicly documented the WMF format as early as the 1992
Windows 3.1 SDK. Since 2007 Microsoft has released the format Windows 3.1 SDK. Since 2007, Microsoft has released the format
specifications [MS-WMF], [MS-EMF], and [MS-EMF+] under its Open specifications [MS-WMF], [MS-EMF], and [MS-EMF+] under its Open
Specification Promise [MS-OSP]. Specification Promise [MS-OSP].
1.2. Windows Bitmaps 1.2. Windows Bitmaps
Long before the invention of Portable Network Graphics (PNG), Long before the invention of Portable Network Graphics (PNG),
Microsoft Corporation and IBM Corporation needed to record images in Microsoft Corporation and IBM Corporation needed to record images in
a format that their applications and operating systems could easily a format that their applications and operating systems could easily
render on low-end machines (Intel 80286). The resulting "BMP" format render on low-end machines (Intel 80286). The resulting "BMP" format
contains a single raster graphic with basic header fields that can be contains a single raster graphic with basic header fields that can be
easily mapped (or "blitted") to locations in memory. As computing easily mapped (or "blitted") to locations in memory. As computing
moved from 16-bit to 32-bit, BMP evolved to contain 32-bit moved from 16-bit to 32-bit, BMP evolved to contain 32-bit
structures. As the 90s wore on, the venerable BMP got boosts with structures. As the '90s wore on, the venerable BMP got boosts with
support for additional color spaces, color profiles, and compression support for additional color spaces, color profiles, and compression
formats. The same basic format can be used to convey 2-bit black-and- formats. The same basic format can be used to convey 2-bit black-
white bitmaps with a 1-bit alpha mask from the '80s, and full-color and-white bitmaps with a 1-bit alpha mask from the '80s, and full-
Ultra HD images on leading-edge displays. BMP is a building block of color Ultra HD images on leading-edge displays. BMP is a building
other formats, including Windows Metafiles, Windows Icons, and block of other formats, including Windows Metafiles, Windows Icons,
Windows Cursors. and Windows Cursors.
Many implementations of BMP were created because of Windows' Many implementations of BMP were created because of Windows'
commercial success in the 1990s. Usage of the format for interchange commercial success in the 1990s. Usage of the format for interchange
has declined since the advent of PNG (for lossless raster graphics) has declined since the advent of PNG (for lossless raster graphics)
and JPEG (for lossy raster graphics); however, a large body of free and JPEG (for lossy raster graphics); however, a large body of free
and commercially available BMP artwork exists. Since Windows Icons and commercially available BMP artwork exists. Since Windows Icons
are a building block of "favicon.ico" Web technology, an implementer are a building block of "favicon.ico" web technology, an implementer
would almost certainly need to support this format for basic would almost certainly need to support this format for basic
interoperability. interoperability.
Microsoft publicly documented the BMP format as early as the 1992 Microsoft publicly documented the BMP format as early as the 1992
Windows 3.1 SDK (in the Windows Metafile documentation). Since 2007 Windows 3.1 SDK (in the Windows Metafile documentation). Since 2007
Microsoft has released the format specification [MS-WMF], which Microsoft has released the format specification [MS-WMF], which
includes most components of the Windows Bitmap format, under its Open includes most components of the Windows Bitmap format, under its Open
Specification Promise [MS-OSP]. See Section 2.2.2.9 of [MS-WMF] Specification Promise [MS-OSP]. See Section 2.2.2.9 of [MS-WMF]
(DeviceIndependentBitmap Object). BMP data begins with a (DeviceIndependentBitmap Object). BMP data begins with a
BITMAPFILEHEADER and is followed by one of the bitmap headers BITMAPFILEHEADER and is followed by one of the bitmap headers
(BITMAPINFOHEADER, BITMAPV4HEADER, or BITMAPV5HEADER), optional color (BITMAPINFOHEADER, BITMAPV4HEADER, or BITMAPV5HEADER), optional color
table data, bitmap data, and optional profile data, in that order table data, bitmap data, and optional profile data, in that order
[BMPSTOR]. [BMPSTOR].
1.3. Definitions Implementers need to be aware of the [MICE] vulnerability, and to
guard against it. Some details are included in the completed
The key word "SHOULD" in this document is to be interpreted as registration template.
described in [RFC2119].
2. Windows Metafile Media Type Registration Application 2. Windows Metafile Media Type Registration Application
Type name: image Type name: image
Subtype name: wmf Subtype name: wmf
Required parameters: None. Required parameters: None.
Optional parameters: Optional parameters:
DEFAULT_CHARSET: The character set intended when the CharacterSet DEFAULT_CHARSET: The character set intended when the CharacterSet
Enumeration (see [MS-WMF]) specifies DEFAULT_CHARSET. The value of enumeration (see the WMF specification) specifies
this parameter is a charset name defined in accordance to the DEFAULT_CHARSET. The value of this parameter is a charset from
procedures laid out in [RFC2978]. When this parameter is not the IANA "Character Sets" registry
specified, DEFAULT_CHARSET has the following meaning in [MS-WMF]: <http://www.iana.org/assignments/character-sets>. When this
"a character set based on the current system locale; for example, parameter is not specified, DEFAULT_CHARSET has the following
when the system locale is United States English, the default meaning in the WMF specification: "a character set based on the
character set is ANSI_CHARSET" (which is Windows-1252, more-or- current system locale; for example, when the system locale is
less). I.e., when not specified, the default character set is United States English, the default character set is
system-dependent. As this optional parameter is novel, content ANSI_CHARSET" (which is Windows-1252, more or less). That is,
producers embedding text SHOULD use EMF instead of WMF (or if when not specified, the default character set is system
absolutely necessary, SHOULD embed EMF within WMF). dependent. This optional parameter is new to this registration
and may not enjoy widespread support for some time. Therefore,
EMF instead of WMF (or if necessary under the circumstances,
embedded EMF within WMF) is a more sensible choice when text is
present.
Encoding considerations: Binary. Encoding considerations: Binary.
Security considerations: Security considerations:
The Windows Metafile format's security history is punctuated in The Windows Metafile format's security history is punctuated in
2005-2006 with the disclosure of the Metafile Image Code Execution 2005-2006 with the disclosure of the Metafile Image Code Execution
vulnerability, codenamed MICE. MICE won the 2007 Pwnie Award for ("MICE") vulnerability. MICE won the 2007 Pwnie Award for "Mass
"Mass 0wnage" and "Breaking the Internet" [PWNIES07]. The official 0wnage" and "Breaking the Internet". The official Microsoft
Microsoft security bulletin [MICE] describes that the flaw occurs security bulletin describes that the flaw occurs because Windows
because Windows Metafiles can set the SETABORTPROC value of the Metafiles can set the SETABORTPROC value of the MetafileEscapes
MetafileEscapes enumeration (accessible via the META_ESCAPE enumeration (accessible via the META_ESCAPE record), allowing for
record), allowing for arbitrary code execution. arbitrary code execution, i.e., "active content".
Windows Metafiles can contain Enhanced Metafiles using the Windows Metafiles can contain Enhanced Metafiles using the
META_ESCAPE_ENHANCED_METAFILE record; thus, the security META_ESCAPE_ENHANCED_METAFILE record; thus, the security
considerations of EMF apply to WMF. considerations of EMF apply to WMF.
Windows Metafiles are historically very buggy. As the original Windows Metafiles are historically very buggy. As the original
intent was to replicate Windows GDI calls, flaws in GDI, or in a intent was to replicate Windows GDI calls, flaws in GDI, or in a
display or printer driver implementing the back-end to GDI, could display or printer driver implementing the backend to GDI, could
be exploitable. WMF implementations not backed by Windows GDI have be exploitable. WMF implementations not backed by Windows GDI
different risks: namely, while a malicious WMF author may not have different risks: namely, while a malicious WMF author may not
consider the non-Windows GDI implementation as a primary target, consider the non-Windows GDI implementation as a primary target,
WMF has many "corner case" records for which an implementation's WMF has many "corner case" records for which an implementation's
processing may not have received the same level of scrutiny as the processing may not have received the same level of scrutiny as the
Windows implementation. "Fuzzing" the implementation is Windows implementation. "Fuzzing" the implementation is
appropriate. appropriate.
As a "basic" image format, the image/wmf media type does not
employ executable content and provides no facilities for privacy
or integrity.
Interoperability considerations: Interoperability considerations:
Windows Metafile is the original 16-bit metafile format; it was Windows Metafile is the original 16-bit metafile format; it was
released in 1990 at what some computer historians might consider released in 1990 at what some computer historians might consider
the "zenith" of the desktop publishing revolution. Accordingly, the "zenith" of the desktop publishing revolution. Accordingly,
there is a large body of free and commercially available clip art there is a large body of free and commercially available clip art
that is still in use, either independently or embedded in that is still in use, either independently or embedded in
productivity documents (word processing documents, desktop productivity documents (word processing documents, desktop
publishing documents, slideshows and presentations, and publishing documents, slideshows, presentations, spreadsheets, and
spreadsheets and workbooks). For example, references to WMF content workbooks). For example, references to WMF content appear (non-
appear (non-normatively) in Office Open XML [OOXML]. To say that normatively) in Office Open XML. To say that support for this
support for this format is necessary for interoperability would not format is necessary for interoperability would not be an
be an understatement. understatement.
Accommodations for comments or arbitrary data storage in Windows Accommodations for comments or arbitrary data storage in Windows
Metafiles are virtually non-existent. However, Windows Metafiles Metafiles are virtually non-existent. However, Windows Metafiles
can contain Enhanced Metafiles using the can contain Enhanced Metafiles using the
META_ESCAPE_ENHANCED_METAFILE record; an implementation SHOULD be META_ESCAPE_ENHANCED_METAFILE record, so an implementation that
able to handle both types. Windows Metafiles can store and output handles Windows Metafiles is also expected to handle enhanced
text strings (see META_TEXTOUT and META_EXTTEXTOUT records), but metafile content. Windows Metafiles can store and output text
the encodings of the strings may be ambiguous. Unicode encodings strings (see META_TEXTOUT and META_EXTTEXTOUT records), but the
are not possible without the DEFAULT_CHARSET parameter defined in encodings of the strings may be ambiguous. Unicode encodings are
this registration. not possible without the DEFAULT_CHARSET parameter defined in this
registration.
The previously unregistered type "image/x-wmf" is also in wide use. The previously unregistered type image/x-wmf is also in wide use.
Accordingly, it is registered as a deprecated alias. See Appendix A Accordingly, it is registered as a deprecated alias.
and Section 4.2.9 of [RFC6838].
Published specification: [MS-WMF]. Published specification:
WMF: Microsoft Corporation, "[MS-WMF]: Windows Metafile Format",
v20160714 (Rev 13.1), July 2016,
<http://msdn.microsoft.com/library/cc250370>.
Applications that use this media type: Applications that use this media type:
Office productivity applications; clip art applications; desktop Office productivity applications; clip art applications; desktop
publishing applications; some Web browsers (e.g., Internet publishing applications; some web browsers (e.g., Internet
Explorer). Explorer).
Fragment identifier considerations: None. Fragment identifier considerations: None.
Additional information: Additional information:
Deprecated alias names for this type: image/x-wmf Deprecated alias names for this type: image/x-wmf
Magic number(s): D7 CD C6 9A (little-endian DWORD 0x9AC6CDD7)
File extension(s): .wmf Magic number(s): D7 CD C6 9A (little-endian DWORD 0x9AC6CDD7)
Macintosh file type code(s):
None. A uniform type identifier (UTI) of "com.microsoft.wmf" is File extension(s): .wmf
RECOMMENDED.
Macintosh file type code(s):
None. A uniform type identifier (UTI) of "com.microsoft.wmf"
is suggested.
Person & email address to contact for further information: Person & email address to contact for further information:
Sean Leonard <dev+ietf@seantek.com> Sean Leonard <dev+ietf@seantek.com>
Restrictions on usage: None. Restrictions on usage: None.
Author/Change controller: Sean Leonard <dev+ietf@seantek.com> Author/Change controller: Sean Leonard <dev+ietf@seantek.com>
Intended usage: COMMON Intended usage: COMMON
Provisional registration? No Provisional registration? No
3. Enhanced Metafile Media Type Registration Application 3. Enhanced Metafile Media Type Registration Application
Type name: image Type name: image
Subtype name: emf Subtype name: emf
Required parameters: None. Required parameters: None.
Optional parameters: None. Optional parameters: None.
Encoding considerations: Binary. Encoding considerations: Binary.
Security considerations: Security considerations:
Enhanced Metafiles are not afflicted with [MICE]. There has been no Enhanced Metafiles are not afflicted with the Metafile Image Code
public disclosure of vulnerabilities specific to EMF or EMF+ to Execution ("MICE") vulnerability. There has been no public
date. Nonetheless: disclosure of vulnerabilities specific to EMF or EMF+ to date.
Neither EMF nor EMF+ are designed to contain "active content".
Nonetheless, Enhanced Metafiles can contain Encapsulated
PostScript (EPS) data; thus, the security considerations of
PostScript processing may also apply to EMF.
Enhanced Metafiles can contain Encapsulated PostScript (EPS) data; As the original intent was to replicate Windows GDI calls, flaws
thus the security considerations of PostScript processing may also in GDI, or in a display or printer driver implementing the backend
apply to EMF. to GDI, could be exploitable with maliciously crafted EMF content.
EMF implementations not backed by Windows GDI have different
risks: namely, while a malicious EMF author may not consider the
non-Windows GDI implementation as a primary target, EMF has many
"corner case" records for which an implementation's processing may
not have received the same level of scrutiny as the Windows
implementation. "Fuzzing" the implementation is appropriate. It
is also possible that EMF+ data is "safe" while EMF data contains
an exploit (or vice versa); the EMF+-aware implementation (such as
an application designed for GDI+ on Windows XP or above) would
skip the "unsafe" data while another implementation would fall
prey to the exploit.
As the original intent was to replicate Windows GDI calls, flaws in As a "basic" image format, the image/emf media type does not
GDI, or in a display or printer driver implementing the back-end to employ executable content and provides no facilities for privacy
GDI, could be exploitable with maliciously crafted EMF content. EMF or integrity.
implementations not backed by Windows GDI have different risks:
namely, while a malicious EMF author may not consider the non-
Windows GDI implementation as a primary target, EMF has many
"corner case" records for which an implementation's processing may
not have received the same level of scrutiny as the Windows
implementation. "Fuzzing" the implementation is appropriate. It is
also possible that EMF+ data is "safe" while EMF data contains an
exploit (or vice-versa); the EMF+-aware implementation (such as an
application designed for GDI+ on Windows XP or above) would skip
the "unsafe" data while another implementation would fall prey to
the exploit.
Interoperability considerations: Interoperability considerations:
Enhanced Metafile is the 32-bit metafile format; it was released in Enhanced Metafile is the 32-bit metafile format; it was released
1992 along with Windows NT 3.1. There is a large body of free and in 1992 along with Windows NT 3.1. There is a large body of free
commercially available clip art that is still in use, either and commercially available clip art that is still in use, either
independently or embedded in productivity documents (word independently or embedded in productivity documents (word
processing documents, desktop publishing documents, slideshows and processing documents, desktop publishing documents, slideshows,
presentations, and spreadsheets and workbooks). To say that support presentations, spreadsheets, and workbooks). To say that support
for this format is necessary for interoperability would not be an for this format is necessary for interoperability would not be an
understatement. understatement.
Enhanced Metafiles have extensive accommodations for comments and Enhanced Metafiles have extensive accommodations for comments and
arbitrary data storage. Enhanced Metafiles can store and output arbitrary data storage. Enhanced Metafiles can store and output
text strings. Mercifully, the encodings of these strings are well- text strings. Mercifully, the encodings of these strings are
defined. Record examples include EMR_EXTTEXTOUTA (US-ASCII), well-defined. Record examples include EMR_EXTTEXTOUTA (US-ASCII),
EMR_EXTTEXTOUTW (UTF16-LE), EMR_POLYTEXTOUTA (US-ASCII), EMR_EXTTEXTOUTW (UTF16-LE), EMR_POLYTEXTOUTA (US-ASCII),
EMR_POLYTEXTOUTW (UTF16-LE), and EMR_SMALLTEXTOUT (UTF16-LE or the EMR_POLYTEXTOUTW (UTF16-LE), and EMR_SMALLTEXTOUT (UTF16-LE or the
low-order 8 bits of UTF16-LE--effectively ISO-8859-1--depending on low-order 8 bits of UTF16-LE -- effectively ISO-8859-1 --
ETO_SMALL_CHARS). depending on ETO_SMALL_CHARS).
Enhanced Metafiles can contain Encapsulated PostScript (EPS) data Enhanced Metafiles can contain Encapsulated PostScript (EPS) data
in the EpsData object [MS-EMF]. The FormatSignature EPS_SIGNATURE in the EpsData object. The FormatSignature EPS_SIGNATURE
(0x46535045, in little-endian) is used instead of ENHMETA_SIGNAUTRE (0x46535045, in little-endian) is used instead of
(0x464D4520, in little-endian) in such a case. ENHMETA_SIGNAUTRE (0x464D4520, in little-endian) in such a case.
Windows XP introduced the GDI+ API, along with EMF+ [MS-EMF+]. EMF+ Windows XP introduced the GDI+ API, along with EMF+. EMF+ is
is actually an embedded format in which GDI+ commands are stored as actually an embedded format in which GDI+ commands are stored as
EMF comment records (EMR_COMMENT_EMFPLUS record type). Content EMF comment records (EMR_COMMENT_EMFPLUS record type). Content
containing EMF+ data can be identified as "EMF+ Only" (only EMF+; containing EMF+ data can be identified as "EMF+ Only" (only EMF+;
the EMF records are not sufficient to reconstitute the drawing) or the EMF records are not sufficient to reconstitute the drawing) or
"EMF+ Dual" (both EMF records alone or EMF+ records alone, when "EMF+ Dual" (both EMF records alone or EMF+ records alone, when
played back, are sufficient to reconstitute the drawing) [MS-EMF+]. played back, are sufficient to reconstitute the drawing). Support
Support for EMF+ records may not be as extensive as support for the for EMF+ records may not be as extensive as support for the
original EMF records. original EMF records.
The previously unregistered type "image/x-emf" is also in wide use. The previously unregistered type image/x-emf is also in wide use.
Accordingly, it is registered as a deprecated alias. See Appendix A Accordingly, it is registered as a deprecated alias.
and Section 4.2.9 of [RFC6838].
Published specification: [MS-EMF] and [MS-EMF+]. Published specification:
EMF: Microsoft Corporation, "[MS-EMF]: Enhanced Metafile Format",
v20160714 (Rev 12.0), July 2016,
<http://msdn.microsoft.com/library/cc230514>.
EMF+: Microsoft Corporation, "[MS-EMFPLUS]: Enhanced Metafile
Format Plus Extensions", v20160714 (Rev 14.1), July 2016,
<http://msdn.microsoft.com/library/cc230724>.
Applications that use this media type: Applications that use this media type:
Office productivity applications; clip art applications; desktop Office productivity applications; clip art applications; desktop
publishing applications; some Web browsers (e.g., Internet publishing applications; some web browsers (e.g., Internet
Explorer). Explorer).
Fragment identifier considerations: None. Fragment identifier considerations: None.
Additional information: Additional information:
Deprecated alias names for this type: image/x-emf Deprecated alias names for this type: image/x-emf
Magic number(s): 01 00 00 00 (little-endian DWORD 0x00000001),
corresponding to the EMR_HEADER Type field.
The next field (EMR_HEADER Size) should be
at least 88 (little-endian DWORD 0x00000050).
File extension(s): .emf
(for both EMF and EMF+ content)
Macintosh file type code(s):
None. A uniform type identifier (UTI) of "com.microsoft.emf" is Magic number(s):
RECOMMENDED. 01 00 00 00 (little-endian DWORD 0x00000001), corresponding to
the EMR_HEADER Type field.
The next field (EMR_HEADER Size) should be at least 88 (little-
endian DWORD 0x00000050).
File extension(s): .emf (for both EMF and EMF+ content)
Macintosh file type code(s):
None. A uniform type identifier (UTI) of "com.microsoft.emf"
is suggested.
Person & email address to contact for further information: Person & email address to contact for further information:
Sean Leonard <dev+ietf@seantek.com> Sean Leonard <dev+ietf@seantek.com>
Restrictions on usage: None. Restrictions on usage: None.
Author/Change controller: Sean Leonard <dev+ietf@seantek.com> Author/Change controller: Sean Leonard <dev+ietf@seantek.com>
Intended usage: COMMON Intended usage: COMMON
Provisional registration? No Provisional registration? No
4. Windows Bitmap Media Type Registration Application 4. Windows Bitmap Media Type Registration Application
Type name: image Type name: image
Subtype name: bmp Subtype name: bmp
Required parameters: None. Required parameters: None.
Optional parameters: None. Optional parameters: None.
Encoding considerations: Binary. Encoding considerations: Binary.
Security considerations: Security considerations:
Bitmaps have a mostly unremarkable security history. Bitmaps have a mostly unremarkable security history.
Because BMP data can encapsulate JPEG or PNG data (BI_JPEG, BI_PNG Because BMP data can encapsulate JPEG or PNG data (BI_JPEG, BI_PNG
values of the Compression enumeration in Section 2.1.1.7 of [MS- values of the Compression enumeration in Section 2.1.1.7 of the
WMF]), the security considerations of JPEG and PNG processing may WMF specification), the security considerations of JPEG and PNG
also apply to BMP. processing may also apply to BMP.
As a "basic" image format, the image/bmp media type does not
employ executable content and provides no facilities for privacy
or integrity.
Interoperability considerations: Interoperability considerations:
Uncompressed Windows Bitmaps can be rather large. If there is a Uncompressed Windows Bitmaps can be rather large. If there is a
need to compress an image, modern applications SHOULD consider need to compress an image, modern applications should consider
emitting JPEG or PNG data instead of embedding them in BMP emitting JPEG or PNG data instead of embedding them in BMP
payloads. payloads.
Published specification: [MS-WMF] and [BMPSTOR]. Published specification:
WMF: Microsoft Corporation, "[MS-WMF]: Windows Metafile Format",
v20160714 (Rev 13.1), July 2016,
<http://msdn.microsoft.com/library/cc250370>.
BMP: Microsoft Corporation, "Bitmap Storage", MSDN ID dd183391,
<http://msdn.microsoft.com/library/dd183391>.
Applications that use this media type: Applications that use this media type:
Office productivity applications; clip art applications; desktop Office productivity applications; clip art applications; desktop
publishing applications; Web browsers; graphics processing publishing applications; web browsers; graphics processing
applications. applications.
Fragment identifier considerations: None. Fragment identifier considerations: None.
Additional information: Additional information:
Magic number(s): 42 4D ("BM"), meaning "bitmap". The next Magic number(s):
field (BITMAPFILEHEADER bfSize) is a 42 4D ("BM"), meaning "bitmap". The next field
little-endian DWORD indicating the size (BITMAPFILEHEADER bfSize) is a little-endian DWORD indicating
of the bitmap content in bytes. the size of the bitmap content in bytes.
File extension(s): .bmp, .dib
Macintosh file type code(s): File extension(s): .bmp, .dib
"BMP ", "BMPf", or "BMPp". Apple has promulgated a
uniform type identifier (UTI) of "com.microsoft.bmp". Macintosh file type code(s):
"BMP ", "BMPf", or "BMPp". Apple has promulgated a uniform
type identifier (UTI) of "com.microsoft.bmp".
Person & email address to contact for further information: Person & email address to contact for further information:
Sean Leonard <dev+ietf@seantek.com> Sean Leonard <dev+ietf@seantek.com>
Restrictions on usage: None. Restrictions on usage: None.
Author/Change controller: Sean Leonard <dev+ietf@seantek.com> Author/Change controller: Sean Leonard <dev+ietf@seantek.com>
Intended usage: COMMON Intended usage: COMMON
Provisional registration? No Provisional registration? No
5. IANA Considerations 5. IANA Considerations
IANA is asked to register the media types image/wmf, image/x-wmf, IANA has registered the media types image/wmf, image/x-wmf,
image/emf, image/x-emf, and image/bmp in the Standards tree using the image/emf, image/x-emf, and image/bmp in the standards tree using the
applications provided in Sections 2, 3, and 4 of this document. applications provided in Sections 2, 3, and 4 of this document.
5. Security Considerations 6. Security Considerations
See the registration templates for their respective security See the registration templates for their respective security
considerations. considerations.
6. References The Metafile Image Code Execution (MICE) vulnerability won the 2007
Pwnie Award for "Mass 0wnage" and "Breaking the Internet" [PWNIES07].
6.1. Normative References 7. References
[BMPSTOR] Microsoft Corporation, "Bitmap Storage", 7.1. Normative References
MSDN ID dd183391, 2014,
<http://msdn.microsoft.com/library/dd183391>.
[MS-WMF] Microsoft Corporation, "Windows Metafile Format", [BMPSTOR] Microsoft Corporation, "Bitmap Storage", MSDN ID dd183391,
[MS-WMF], v20140502 (Rev 11.1), May 2014, <http://msdn.microsoft.com/library/dd183391>.
<http://msdn.microsoft.com/library/cc250370>.
[MS-EMF] Microsoft Corporation, "Enhanced Metafile Format", [MS-EMF] Microsoft Corporation, "[MS-EMF]: Enhanced Metafile
[MS-EMF], v20140502 (Rev 10.0), May 2014, Format", v20160714 (Rev 12.0), July 2016,
<http://msdn.microsoft.com/library/cc230514>. <http://msdn.microsoft.com/library/cc230514>.
[MS-EMF+] Microsoft Corporation, "Enhanced Metafile Format Plus [MS-EMF+] Microsoft Corporation, "[MS-EMFPLUS]: Enhanced Metafile
Extensions", [MS-EMFPLUS], v20140502 (Rev 13.0), May 2014, Format Plus Extensions", v20160714 (Rev 14.1), July 2016,
<http://msdn.microsoft.com/library/cc230724>. <http://msdn.microsoft.com/library/cc230724>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [MS-WMF] Microsoft Corporation, "[MS-WMF]: Windows Metafile
Requirement Levels", BCP 14, RFC 2119, March 1997. Format", v20160714 (Rev 13.1), July 2016,
<http://msdn.microsoft.com/library/cc250370>.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013.
6.2. Informative References 7.2. Informative References
[MICE] Microsoft Corporation, "Vulnerability in Graphics [MICE] Microsoft Corporation, "Vulnerability in Graphics
Rendering Engine Could Allow Remote Code Execution Rendering Engine Could Allow Remote Code Execution
(912919)", MS06-001, V1.0, January 2006, (912919)", MS06-001, V1.0, January 2006,
<https://technet.microsoft.com/library/security/ms06-001>. <https://technet.microsoft.com/library/security/ms06-001>.
[MS-OSP] Microsoft Corporation, "Open Specification Promise", [MS-OSP] Microsoft Corporation, "Open Specification Promise",
February 2007, February 2007, <https://msdn.microsoft.com/
<http://www.microsoft.com/interop/osp/default.mspx>. en-us/openspecifications/dn646765>.
[OOXML] Ecma International, "Office Open XML File Formats", [OOXML] Ecma International, "Office Open XML File Formats",
Standard ECMA-376, Fourth Edition, ISO/IEC 29500, December Standard ECMA-376, Fourth Edition, ISO/IEC 29500, December
2012, <http://www.ecma-international.org/publications/ 2012, <http://www.ecma-international.org/publications/
standards/Ecma-376.htm>. standards/Ecma-376.htm>.
[PWNIES07] Pwnie Awards LLC, "Pwnie Awards 2007", 2007, [PWNIES07] Pwnie Awards LLC, "Winners of Pwnie Awards 2007", 2007,
<http://pwnies.com/archive/2007/winners/>. <http://pwnies.com/archive/2007/winners/>.
Author's Address Author's Address
Sean Leonard Sean Leonard
Penango, Inc. Penango, Inc.
5900 Wilshire Boulevard 5900 Wilshire Boulevard
21st Floor 21st Floor
Los Angeles, CA 90036 Los Angeles, CA 90036
USA United States of America
EMail: dev+ietf@seantek.com Email: dev+ietf@seantek.com
URI: http://www.penango.com/ URI: http://www.penango.com/
 End of changes. 78 change blocks. 
253 lines changed or deleted 296 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/