idnits 2.17.1 draft-seantek-windows-image-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 6, 2016) is 2972 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MS-EMFPLUS' is mentioned on line 444, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Leonard 3 Internet-Draft Penango, Inc. 4 Intended Status: Informational March 6, 2016 5 Expires: September 7, 2016 7 Windows Image Media Types 8 draft-seantek-windows-image-02 10 Abstract 12 This document registers media types for certain image formats 13 promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, 14 image/emf, image/x-emf, and image/bmp for use with Windows Metafile, 15 Enhanced Metafile, and Windows Bitmap formats. Originally designed 16 for Microsoft Windows 2.0 and 3.0, these image files are intended to 17 be portable between applications and devices, and may contain both 18 vector and raster graphics. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 1.1. Windows Metafiles 54 Long before the invention of Scalable Vector Graphics, Microsoft 55 Corporation recognized the value of recording images in a format that 56 its applications and operating systems could easily render 57 irrespective of the output device. With the release of Windows 3.0, 58 Microsoft released its Windows Metafile (WMF) format, which can 59 contain vector and raster graphics in one package. As a binary format 60 that needed to work on 16-bit machines, WMF is comprised of a 61 sequence of record structures. Each record contains drawing commands, 62 object definitions, and configuration settings. When a metafile is 63 processed, the image can be rendered on a display, output to a 64 printer or plotter, stored in memory, or saved to some persistent 65 storage. Reflecting the relationship to the Windows Graphics Device 66 Interface (GDI) API, WMF metafiles are "played" to a playback device 67 context in the same manner that PostScript content is treated as an 68 executable program that results in the output of the original 69 document. 71 As Microsoft's first 32-bit operating system, Windows NT 3.1 72 introduced an overhaul to the Windows API ("Win32") and the in-memory 73 formats upon which those APIs relied. The Enhanced Metafile (EMF) 74 format was created at this time, using 32-bit values instead of WMF's 75 16-bit values. In Windows XP, Microsoft extended EMF with "EMF+", 76 adding support for Windows GDI+. 78 Many implementations of WMF and EMF were created because of Windows' 79 commercial success in the 1990s. A large body of free and 80 commercially available clip art and other artwork exists in this 81 format. Furthermore, WMF content appears non-normatively in certain 82 standards (e.g., [OOXML]); the usage is common enough that an 83 implementer would almost certainly need to support it for basic 84 interoperability. 86 Microsoft publicly documented the WMF format as early as the 1992 87 Windows 3.1 SDK. Since 2007 Microsoft has released the format 88 specifications [MS-WMF], [MS-EMF], and [MS-EMF+] under its Open 89 Specification Promise [MS-OSP]. 91 1.2. Windows Bitmaps 93 Long before the invention of Portable Network Graphics (PNG), 94 Microsoft Corporation and IBM Corporation needed to record images in 95 a format that their applications and operating systems could easily 96 render on low-end machines (Intel 80286). The resulting "BMP" format 97 contains a single raster graphic with basic header fields that can be 98 easily mapped (or "blitted") to locations in memory. As computing 99 moved from 16-bit to 32-bit, BMP evolved to contain 32-bit 100 structures. As the 90s wore on, the venerable BMP got boosts with 101 support for additional color spaces, color profiles, and compression 102 formats. The same basic format can be used to convey 2-bit black-and- 103 white bitmaps with a 1-bit alpha mask from the '80s, and full-color 104 Ultra HD images on leading-edge displays. BMP is a building block of 105 other formats, including Windows Metafiles, Windows Icons, and 106 Windows Cursors. 108 Many implementations of BMP were created because of Windows' 109 commercial success in the 1990s. Usage of the format for interchange 110 has declined since the advent of PNG (for lossless raster graphics) 111 and JPEG (for lossy raster graphics); however, a large body of free 112 and commercially available BMP artwork exists. Since Windows Icons 113 are a building block of "favicon.ico" Web technology, an implementer 114 would almost certainly need to support this format for basic 115 interoperability. 117 Microsoft publicly documented the BMP format as early as the 1992 118 Windows 3.1 SDK (in the Windows Metafile documentation). Since 2007 119 Microsoft has released the format specification [MS-WMF], which 120 includes most components of the Windows Bitmap format, under its Open 121 Specification Promise [MS-OSP]. See Section 2.2.2.9 of [MS-WMF] 122 (DeviceIndependentBitmap Object). BMP data begins with a 123 BITMAPFILEHEADER and is followed by one of the bitmap headers 124 (BITMAPINFOHEADER, BITMAPV4HEADER, or BITMAPV5HEADER), optional color 125 table data, bitmap data, and optional profile data, in that order 126 [BMPSTOR]. 128 1.3. Definitions 130 The key word "SHOULD" in this document is to be interpreted as 131 described in [RFC2119]. 133 2. Windows Metafile Media Type Registration Application 135 Type name: image 137 Subtype name: wmf 139 Required parameters: None. 141 Optional parameters: 143 DEFAULT_CHARSET: The character set intended when the CharacterSet 144 Enumeration (see [MS-WMF]) specifies DEFAULT_CHARSET. The value of 145 this parameter is a charset name defined in accordance to the 146 procedures laid out in [RFC2978]. When this parameter is not 147 specified, DEFAULT_CHARSET has the following meaning in [MS-WMF]: 148 "a character set based on the current system locale; for example, 149 when the system locale is United States English, the default 150 character set is ANSI_CHARSET" (which is Windows-1252, more-or- 151 less). I.e., when not specified, the default character set is 152 system-dependent. As this optional parameter is novel, content 153 producers embedding text SHOULD use EMF instead of WMF (or if 154 absolutely necessary, SHOULD embed EMF within WMF). 156 Encoding considerations: Binary. 158 Security considerations: 160 The Windows Metafile format's security history is punctuated in 161 2005-2006 with the disclosure of the Metafile Image Code Execution 162 vulnerability, codenamed MICE. MICE won the 2007 Pwnie Award for 163 "Mass 0wnage" and "Breaking the Internet" [PWNIES07]. The official 164 Microsoft security bulletin [MICE] describes that the flaw occurs 165 because Windows Metafiles can set the SETABORTPROC value of the 166 MetafileEscapes enumeration (accessible via the META_ESCAPE 167 record), allowing for arbitrary code execution. 169 Windows Metafiles can contain Enhanced Metafiles using the 170 META_ESCAPE_ENHANCED_METAFILE record; thus, the security 171 considerations of EMF apply to WMF. 173 Windows Metafiles are historically very buggy. As the original 174 intent was to replicate Windows GDI calls, flaws in GDI, or in a 175 display or printer driver implementing the back-end to GDI, could 176 be exploitable. WMF implementations not backed by Windows GDI have 177 different risks: namely, while a malicious WMF author may not 178 consider the non-Windows GDI implementation as a primary target, 179 WMF has many "corner case" records for which an implementation's 180 processing may not have received the same level of scrutiny as the 181 Windows implementation. "Fuzzing" the implementation is 182 appropriate. 184 Interoperability considerations: 186 Windows Metafile is the original 16-bit metafile format; it was 187 released in 1990 at what some computer historians might consider 188 the "zenith" of the desktop publishing revolution. Accordingly, 189 there is a large body of free and commercially available clip art 190 that is still in use, either independently or embedded in 191 productivity documents (word processing documents, desktop 192 publishing documents, slideshows and presentations, and 193 spreadsheets and workbooks). For example, references to WMF content 194 appear (non-normatively) in Office Open XML [OOXML]. To say that 195 support for this format is necessary for interoperability would not 196 be an understatement. 198 Accommodations for comments or arbitrary data storage in Windows 199 Metafiles are virtually non-existent. However, Windows Metafiles 200 can contain Enhanced Metafiles using the 201 META_ESCAPE_ENHANCED_METAFILE record; an implementation SHOULD be 202 able to handle both types. Windows Metafiles can store and output 203 text strings (see META_TEXTOUT and META_EXTTEXTOUT records), but 204 the encodings of the strings may be ambiguous. Unicode encodings 205 are not possible without the DEFAULT_CHARSET parameter defined in 206 this registration. 208 The previously unregistered type "image/x-wmf" is also in wide use. 209 Accordingly, it is registered as a deprecated alias. See Appendix A 210 and Section 4.2.9 of [RFC6838]. 212 Published specification: [MS-WMF]. 214 Applications that use this media type: 216 Office productivity applications; clip art applications; desktop 217 publishing applications; some Web browsers (e.g., Internet 218 Explorer). 220 Fragment identifier considerations: None. 222 Additional information: 224 Deprecated alias names for this type: image/x-wmf 225 Magic number(s): D7 CD C6 9A (little-endian DWORD 0x9AC6CDD7) 226 File extension(s): .wmf 227 Macintosh file type code(s): 228 None. A uniform type identifier (UTI) of "com.microsoft.wmf" is 229 RECOMMENDED. 231 Person & email address to contact for further information: 233 Sean Leonard 235 Restrictions on usage: None. 237 Author/Change controller: Sean Leonard 239 Intended usage: COMMON 241 Provisional registration? No 243 3. Enhanced Metafile Media Type Registration Application 245 Type name: image 247 Subtype name: emf 249 Required parameters: None. 251 Optional parameters: None. 253 Encoding considerations: Binary. 255 Security considerations: 257 Enhanced Metafiles are not afflicted with [MICE]. There has been no 258 public disclosure of vulnerabilities specific to EMF or EMF+ to 259 date. Nonetheless: 261 Enhanced Metafiles can contain Encapsulated PostScript (EPS) data; 262 thus the security considerations of PostScript processing may also 263 apply to EMF. 265 As the original intent was to replicate Windows GDI calls, flaws in 266 GDI, or in a display or printer driver implementing the back-end to 267 GDI, could be exploitable with maliciously crafted EMF content. EMF 268 implementations not backed by Windows GDI have different risks: 269 namely, while a malicious EMF author may not consider the non- 270 Windows GDI implementation as a primary target, EMF has many 271 "corner case" records for which an implementation's processing may 272 not have received the same level of scrutiny as the Windows 273 implementation. "Fuzzing" the implementation is appropriate. It is 274 also possible that EMF+ data is "safe" while EMF data contains an 275 exploit (or vice-versa); the EMF+-aware implementation (such as an 276 application designed for GDI+ on Windows XP or above) would skip 277 the "unsafe" data while another implementation would fall prey to 278 the exploit. 280 Interoperability considerations: 282 Enhanced Metafile is the 32-bit metafile format; it was released in 283 1992 along with Windows NT 3.1. There is a large body of free and 284 commercially available clip art that is still in use, either 285 independently or embedded in productivity documents (word 286 processing documents, desktop publishing documents, slideshows and 287 presentations, and spreadsheets and workbooks). To say that support 288 for this format is necessary for interoperability would not be an 289 understatement. 291 Enhanced Metafiles have extensive accommodations for comments and 292 arbitrary data storage. Enhanced Metafiles can store and output 293 text strings. Mercifully, the encodings of these strings are well- 294 defined. Record examples include EMR_EXTTEXTOUTA (US-ASCII), 295 EMR_EXTTEXTOUTW (UTF16-LE), EMR_POLYTEXTOUTA (US-ASCII), 296 EMR_POLYTEXTOUTW (UTF16-LE), and EMR_SMALLTEXTOUT (UTF16-LE or the 297 low-order 8 bits of UTF16-LE--effectively ISO-8859-1--depending on 298 ETO_SMALL_CHARS). 300 Enhanced Metafiles can contain Encapsulated PostScript (EPS) data 301 in the EpsData object [MS-EMF]. The FormatSignature EPS_SIGNATURE 302 (0x46535045, in little-endian) is used instead of ENHMETA_SIGNAUTRE 303 (0x464D4520, in little-endian) in such a case. 305 Windows XP introduced the GDI+ API, along with EMF+ [MS-EMF+]. EMF+ 306 is actually an embedded format in which GDI+ commands are stored as 307 EMF comment records (EMR_COMMENT_EMFPLUS record type). Content 308 containing EMF+ data can be identified as "EMF+ Only" (only EMF+; 309 the EMF records are not sufficient to reconstitute the drawing) or 310 "EMF+ Dual" (both EMF records alone or EMF+ records alone, when 311 played back, are sufficient to reconstitute the drawing) [MS-EMF+]. 312 Support for EMF+ records may not be as extensive as support for the 313 original EMF records. 315 The previously unregistered type "image/x-emf" is also in wide use. 316 Accordingly, it is registered as a deprecated alias. See Appendix A 317 and Section 4.2.9 of [RFC6838]. 319 Published specification: [MS-EMF] and [MS-EMF+]. 321 Applications that use this media type: 323 Office productivity applications; clip art applications; desktop 324 publishing applications; some Web browsers (e.g., Internet 325 Explorer). 327 Fragment identifier considerations: None. 329 Additional information: 331 Deprecated alias names for this type: image/x-emf 332 Magic number(s): 01 00 00 00 (little-endian DWORD 0x00000001), 333 corresponding to the EMR_HEADER Type field. 334 The next field (EMR_HEADER Size) should be 335 at least 88 (little-endian DWORD 0x00000050). 336 File extension(s): .emf 337 (for both EMF and EMF+ content) 338 Macintosh file type code(s): 340 None. A uniform type identifier (UTI) of "com.microsoft.emf" is 341 RECOMMENDED. 343 Person & email address to contact for further information: 345 Sean Leonard 347 Restrictions on usage: None. 349 Author/Change controller: Sean Leonard 351 Intended usage: COMMON 353 Provisional registration? No 355 4. Windows Bitmap Media Type Registration Application 357 Type name: image 359 Subtype name: bmp 361 Required parameters: None. 363 Optional parameters: None. 365 Encoding considerations: Binary. 367 Security considerations: 369 Bitmaps have a mostly unremarkable security history. 371 Because BMP data can encapsulate JPEG or PNG data (BI_JPEG, BI_PNG 372 values of the Compression enumeration in Section 2.1.1.7 of [MS- 373 WMF]), the security considerations of JPEG and PNG processing may 374 also apply to BMP. 376 Interoperability considerations: 378 Uncompressed Windows Bitmaps can be rather large. If there is a 379 need to compress an image, modern applications SHOULD consider 380 emitting JPEG or PNG data instead of embedding them in BMP 381 payloads. 383 Published specification: [MS-WMF] and [BMPSTOR]. 385 Applications that use this media type: 387 Office productivity applications; clip art applications; desktop 388 publishing applications; Web browsers; graphics processing 389 applications. 391 Fragment identifier considerations: None. 393 Additional information: 395 Magic number(s): 42 4D ("BM"), meaning "bitmap". The next 396 field (BITMAPFILEHEADER bfSize) is a 397 little-endian DWORD indicating the size 398 of the bitmap content in bytes. 399 File extension(s): .bmp, .dib 400 Macintosh file type code(s): 401 "BMP ", "BMPf", or "BMPp". Apple has promulgated a 402 uniform type identifier (UTI) of "com.microsoft.bmp". 404 Person & email address to contact for further information: 406 Sean Leonard 408 Restrictions on usage: None. 410 Author/Change controller: Sean Leonard 412 Intended usage: COMMON 414 Provisional registration? No 416 5. IANA Considerations 418 IANA is asked to register the media types image/wmf, image/x-wmf, 419 image/emf, image/x-emf, and image/bmp in the Standards tree using the 420 applications provided in Sections 2, 3, and 4 of this document. 422 5. Security Considerations 424 See the registration templates for their respective security 425 considerations. 427 6. References 429 6.1. Normative References 431 [BMPSTOR] Microsoft Corporation, "Bitmap Storage", 432 MSDN ID dd183391, 2014, 433 . 435 [MS-WMF] Microsoft Corporation, "Windows Metafile Format", 436 [MS-WMF], v20140502 (Rev 11.1), May 2014, 437 . 439 [MS-EMF] Microsoft Corporation, "Enhanced Metafile Format", 440 [MS-EMF], v20140502 (Rev 10.0), May 2014, 441 . 443 [MS-EMF+] Microsoft Corporation, "Enhanced Metafile Format Plus 444 Extensions", [MS-EMFPLUS], v20140502 (Rev 13.0), May 2014, 445 . 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, March 1997. 450 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 451 Procedures", BCP 19, RFC 2978, October 2000. 453 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 454 Specifications and Registration Procedures", BCP 13, RFC 455 6838, January 2013. 457 6.2. Informative References 459 [MICE] Microsoft Corporation, "Vulnerability in Graphics 460 Rendering Engine Could Allow Remote Code Execution 461 (912919)", MS06-001, V1.0, January 2006, 462 . 464 [MS-OSP] Microsoft Corporation, "Open Specification Promise", 465 February 2007, 466 . 468 [OOXML] Ecma International, "Office Open XML File Formats", 469 Standard ECMA-376, Fourth Edition, ISO/IEC 29500, December 470 2012, . 473 [PWNIES07] Pwnie Awards LLC, "Pwnie Awards 2007", 2007, 474 . 476 Author's Address 478 Sean Leonard 479 Penango, Inc. 480 5900 Wilshire Boulevard 481 21st Floor 482 Los Angeles, CA 90036 483 USA 485 EMail: dev+ietf@seantek.com 486 URI: http://www.penango.com/