Subject: [media-types] image/wmf and image/emf: New Version Notification for draft-seantek-image-wmf-emf-00.txt

From: Sean Leonard <[email-masked]>
Date: Fri, 17 Oct 2014 11:08:25 -0700

Colleagues:

An Internet-Draft to register image/wmf and image/emf has been posted.

Thanks to Alexey Melnikov and Dave Thaler, who provided advice on these drafts prior to submission.

Feedback welcome.

Regards,

Sean

*******************
A new version of I-D, draft-seantek-image-wmf-emf-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-image-wmf-emf
Revision:	00
Title:		The Windows Metafile and Enhanced Metafile Media Types
Document date:	2014-10-17
Group:		Individual Submission
Pages:		8
URL:            http://www.ietf.org/internet-drafts/draft-seantek-image-wmf-emf-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-image-wmf-emf/
Htmlized:       http://tools.ietf.org/html/draft-seantek-image-wmf-emf-00

Abstract:
 This document registers the image/wmf and image/emf media types for
 use with Windows Metafile and Enhanced Metafile formats. Originally
 designed for Microsoft Windows 3.0, these image files are intended to
 be portable between applications and devices, and may contain both
 vector and raster graphics.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Libbrecht <[email-masked]>
Date: Fri, 17 Oct 2014 22:38:51 +0200

Sean,

I believe the etiquette of this lists asks you that you copy the content of the media-type registration into here.

I see in the links you provided that the wmf and emf registration indicate an amount of question marks as Macintosh file types and Uniform types… it seems unfinished or is that a question?
(as of today, many agree that Macintosh file types are not useful anymore, so that can probably be ignored, but not UTIs!)

Also I see that you attempted to include Macintosh UTIs for all formats, that is a good and desirable thing.
Any reason you do not also mention (just besides that , I would say) the Windows clipboard names for each of these formats? I am pretty sure something can be found in some MicroSoft documentation about it.

thanks

paul

On 17 oct. 2014, at 20:08, Sean Leonard <[email-masked]> wrote:

> The IETF Secretariat_______________________________________________
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: Sean Leonard <[email-masked]>
Date: Fri, 17 Oct 2014 13:42:56 -0700

> I believe the etiquette of this lists asks you that you copy the content of the media-type registration into here.

Ok. I did not want to be spammy. But, I'll do that..in two separate 
e-mails. The I-D includes two registrations.

> (as of today, many agree that Macintosh file types are not useful anymore, so that can probably be ignored, but not UTIs!)

They are questions. I did some research but was unable to find file 
types or UTIs. I did not want to propose something new unless we are 
100% sure that there are no other file types or UTIs in use for WMF/EMF.

> Any reason you do not also mention (just besides that , I would say) the Windows clipboard names for each of these formats? I am pretty sure something can be found in some MicroSoft documentation a…

I was not aware of the Windows clipboard names either. It is a good 
point, however, to include. If you find something let me know; otherwise 
I'll make it a point for draft-01 to research more.

Thanks,

Sean

---

From: Sean Leonard <[email-masked]>
Date: Fri, 17 Oct 2014 13:45:09 -0700

2. Windows Metafile Media Type Registration Application

    Type name: image

    Subtype name: wmf

    Required parameters: None.

    Optional parameters:

     DEFAULT_CHARSET: The character set intended when the CharacterSet
      Enumeration (see [MS-WMF]) specifies DEFAULT_CHARSET. The value of
      this parameter is a charset name defined in accordance to the
      procedures laid out in [RFC2978]. When this parameter is not
      specified, DEFAULT_CHARSET has the following meaning in [MS-WMF]:
      "a character set based on the current system locale; for example,
      when the system locale is United States English, the default
      character set is ANSI_CHARSET" (which is Windows-1252, more-or-
      less). I.e., when not specified, the default character set is
      system-dependent. As this optional parameter is novel, content
      producers embedding text SHOULD use EMF instead of WMF (or if
      absolutely necessary, SHOULD embed EMF within WMF).

    Encoding considerations: Binary.

    Security considerations:

      The Windows Metafile format's security history is punctuated in
      2005-2006 with the disclosure of the Metafile Image Code Execution
      vulnerability, codenamed MICE. MICE won the 2007 Pwnie Award for
      "Mass 0wnage" and "Breaking the Internet" [PWNIES07]. The official
      Microsoft security bulletin [MICE] describes that the flaw occurs
      because Windows Metafiles can set the SETABORTPROC value of the
      MetafileEscapes enumeration (accessible via the META_ESCAPE
      record), allowing for arbitrary code execution.

      Windows Metafiles can contain Enhanced Metafiles using the
      META_ESCAPE_ENHANCED_METAFILE record; thus, the security
      considerations of EMF apply to WMF.

      Windows Metafiles are historically very buggy. As the original
      intent was to replicate Windows GDI calls, flaws in GDI, or in a
      display or printer driver implementing the back-end to GDI, could
      be exploitable. WMF implementations not backed by Windows GDI have
      different risks: namely, while a malicious WMF author may not
      consider the non-Windows GDI implementation as a primary target,
      WMF 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.

    Interoperability considerations:

      Windows Metafile is the original 16-bit metafile format; it was
      released in 1990 at what some computer historians might consider
      the "zenith" of the desktop publishing revolution. Accordingly,
      there is a large body of free and commercially available clip art
      that is still in use, either independently or embedded in
      productivity documents (word processing documents, desktop
      publishing documents, slideshows and presentations, and
      spreadsheets and workbooks). For example, references to WMF content
      appear (non-normatively) in Office Open XML [OOXML]. To say that
      support for this format is necessary for interoperability would not
      be an understatement.

      Accommodations for comments or arbitrary data storage in Windows
      Metafiles are virtually non-existent. However, Windows Metafiles
      can contain Enhanced Metafiles using the
      META_ESCAPE_ENHANCED_METAFILE record; an implementation SHOULD be
      able to handle both types. Windows Metafiles can store and output
      text strings (see META_TEXTOUT and META_EXTTEXTOUT records), but
      the encodings of the strings may be ambiguous. Unicode encodings
      are not possible without the DEFAULT_CHARSET parameter defined in
      this registration.

      The previously unregistered type "image/x-wmf" is also in wide use.
      Accordingly, it is registered as a deprecated alias. See Appendix A
      and Section 4.2.9 of [RFC6838].

    Published specification: [MS-WMF].

    Applications that use this media type:

      Office productivity applications; clip art applications; desktop
      publishing applications; some Web browsers (e.g., Internet
      Explorer).

    Fragment identifier considerations: None.

    Additional information:

      Deprecated alias names for this type: image/x-wmf
      Magic number(s): D7 CD C6 9A (little-endian DWORD 0x9AC6CDD7)
      File extension(s): .wmf
      Macintosh file type code(s):
        ????. A uniform type identifier (UTI) of "????" is RECOMMENDED.

    Person & email address to contact for further information:

      Sean Leonard <[email-masked]>

    Restrictions on usage: None.

    Author/Change controller: Sean Leonard <[email-masked]>

    Intended usage: COMMON

    Provisional registration? No

---

From: Sean Leonard <[email-masked]>
Date: Fri, 17 Oct 2014 13:47:18 -0700

3. Enhanced Metafile Media Type Registration Application

    Type name: image

    Subtype name: emf

    Optional parameters: None.

    Security considerations:

      Enhanced Metafiles are not afflicted with [MICE]. There has been no
      public disclosure of vulnerabilities specific to EMF or EMF+ to
      date. Nonetheless:

      Enhanced Metafiles can contain Encapsulated PostScript (EPS) data;
      thus the security considerations of PostScript processing may also
      apply to EMF.

      As the original intent was to replicate Windows GDI calls, flaws in
      GDI, or in a display or printer driver implementing the back-end 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.

      Enhanced Metafile is the 32-bit metafile format; it was released in
      1992 along with Windows NT 3.1. There is a large body of free and
      commercially available clip art that is still in use, either
      independently or embedded in productivity documents (word
      processing documents, desktop publishing documents, slideshows and
      presentations, and spreadsheets and workbooks). To say that support
      for this format is necessary for interoperability would not be an
      understatement.

      Enhanced Metafiles have extensive accommodations for comments and
      arbitrary data storage. Enhanced Metafiles can store and output
      text strings. Mercifully, the encodings of these strings are well-
      defined. Record examples include EMR_EXTTEXTOUTA (US-ASCII),
      EMR_EXTTEXTOUTW (UTF16-LE), EMR_POLYTEXTOUTA (US-ASCII),
      EMR_POLYTEXTOUTW (UTF16-LE), and EMR_SMALLTEXTOUT (UTF16-LE or the
      low-order 8 bits of UTF16-LE--effectively ISO-8859-1--depending on
      ETO_SMALL_CHARS).

      Enhanced Metafiles can contain Encapsulated PostScript (EPS) data
      in the EpsData object [MS-EMF]. The FormatSignature EPS_SIGNATURE
      (0x46535045, in little-endian) is used instead of ENHMETA_SIGNAUTRE
      (0x464D4520, in little-endian) in such a case.

      Windows XP introduced the GDI+ API, along with EMF+ [MS-EMF+]. EMF+
      is actually an embedded format in which GDI+ commands are stored as
      EMF comment records (EMR_COMMENT_EMFPLUS record type). Content
      containing EMF+ data can be identified as "EMF+ Only" (only EMF+;
      the EMF records are not sufficient to reconstitute the drawing) or
      "EMF+ Dual" (both EMF records alone or EMF+ records alone, when
      played back, are sufficient to reconstitute the drawing) [MS-EMF+].
      Support for EMF+ records may not be as extensive as support for the
      original EMF records.

      The previously unregistered type "image/x-emf" is also in wide use.
      Accordingly, it is registered as a deprecated alias. See Appendix A
      and Section 4.2.9 of [RFC6838].

    Published specification: [MS-EMF] and [MS-EMF+].

    Additional information:

      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):
        ????. A uniform type identifier (UTI) of "????" is RECOMMENDED.

    Intended usage: COMMON

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 Oct 2014 23:33:26 -0700

On Fri, Oct 17, 2014 at 1:38 PM, Paul Libbrecht <[email-masked]> wrote:

>
> I believe the etiquette of this lists asks you that you copy the content
> of the media-type registration into here.
>
>
Is that really necessary given it's (presumably) in the referenced document?

It's certainly true that media type registrations have been happening since
long before I was on this list, but it seems an odd thing to me.

-MSK

---

From: Paul Libbrecht <[email-masked]>
Date: Mon, 20 Oct 2014 09:05:26 +0200

> Is that really necessary given it's (presumably) in the referenced document?

I can't find the description of that requirement in https://tools.ietf.org/html/rfc6838#section-5.1 indeed.
I've seen requests for that by others on the mailing-list though.

> It's certainly true that media type registrations have been happening since long before I was on this list, but it seems an odd thing to me.

Personally, I think it makes a lot of sense to keep the core of the registration inside a shared, communication anchored, collection of exchanges such as as mailing-lists as opposed to the publisher-specific specification space or the IETF.

paul

---

From: Sean Leonard <[email-masked]>
Date: Mon, 20 Oct 2014 00:24:15 -0700

On 10/19/2014 11:33 PM, Murray S. Kucherawy wrote:
> On Fri, Oct 17, 2014 at 1:38 PM, Paul Libbrecht <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     I believe the etiquette of this lists asks you that you copy the
>     content of the media-type registration into here.
>
>
> It's certainly true that media type registrations have been happening 
> since long before I was on this list, but it seems an odd thing to me.

I think the list militating the etiquette is [email-masked], not 
[email-masked]. I cross-posted.

For these types of things, should we (shouldn't we) cross-post? If it is 
proposed to go in the standards tree and is not obviously covered by 
another IETF area or working group, and is not from another standards 
organization, it would seem that the proposal should fall into APPSAWG.

Just curious,

Sean

---

From: Ned Freed <[email-masked]>
Date: Mon, 20 Oct 2014 17:35:35 -0700 (PDT)

> > Is that really necessary given it's (presumably) in the referenced

Etiquette != requirement. Nobody ever said it was required; but doing
it may improve your chances of people taking the time to do a review.

> I can't find the description of that requirement in
> https://tools.ietf.org/html/rfc6838#section-5.1 indeed.

> I've seen requests for that by others on the mailing-list though.

Yep. So requirement or not, it's in your best interest to do it.

> > long before I was on this list, but it seems an odd thing to me.

Why?

> Personally, I think it makes a lot of sense to keep the core of the
> registration inside a shared, communication anchored, collection of exchanges
> such as as mailing-lists as opposed to the publisher-specific specification
> space or the IETF.

Exactly right.

				Ned