Internet DRAFT - draft-weatherley-microsoft-windows


Network Working Group                                      R. Weatherley
Internet Draft                                  University of Queensland
                                                              July, 1993

                MIME Content-Types for Microsoft Windows

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.  Internet Drafts are draft
   documents valid for a maximum of six months.  Internet Drafts may be
   updated, replaced, or obsoleted by other documents at any time.  It
   is not appropriate to use Internet Drafts as reference material or to
   cite them other than as a "working draft" or "work in progress".
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the status of this or any other Internet

   Distribution of this memo is unlimited.


   This memo registers MIME [RFC-MIME] Content-Types for a number of
   file formats common to the Microsoft Windows environment.  The
   intention is to aid interoperability between mail systems, and to
   enumerate possible conversions at gateways.

   This document does not provide detailed descriptions of individual
   formats, since published descriptions are already available from
   other sources, notably [SDK4], and are, in some cases, quite complex.


   The majority of the file formats are defined in [SDK4] and [MREF],
   with additional information about the layout of certain data
   structures in [SDK3].

   A requirement for this document was that only formats with a
   previously published description would be registered.  This does not
   preclude the registration of additional Content-Types related to
   Microsoft Windows at some future date, or the use of experimental
   Content-Types beginning with "x-" in the interim.

   Wherever possible, user and message transfer agents should use the

Weatherley              DRAFT - expires 12/1/93                 [Page 1]
RFC DRAFT                                                      July 1993

   standard Content-Types defined in [RFC-MIME], since they aid
   interoperability between mail systems based on Microsoft Windows and
   mail systems based on other environments.  If the conversion of
   information to a standard MIME format is not desirable, the
   mechanisms defined in this document may be used.  Where appropriate,
   standard MIME equivalents of the Microsoft Windows file formats are

General Considerations

   The primary consideration of this memo is interoperability with MIME
   systems which operate in environments where formats specific to
   Microsoft Windows are not native.  Therefore, the set of types
   registered by this memo is quite small and where types defined in
   [RFC-MIME] are sufficient to represent Microsoft Windows data without
   significant loss of information, no new types are registered.  The
   implementation cost of converting Microsoft Windows formats to
   standard MIME types in message composition and gateway software is
   considered minimal compared to having to implement support for such
   formats in every MIME system.

   Some types are designated as likely to be superceded in future
   versions of the central MIME RFC's and are considered a stopgap
   measure until types are available to which conversion is possible
   without loss of information.

   These considerations are tempered by the need to send some documents
   without modification, yet tagged with a suitable Content-Type.  This
   arises from the conceptual difference between a component of a
   message intended to be read when the message is received, and an
   attachment to a message intended to be saved away by the recipient
   for later processing by a tool separate from the MIME system.  So,
   for example, although it is theoretically possible to convert a
   Microsoft Write document (with loss) into a series of text/enriched
   [RFC-RICH] body parts and embedded objects, this probably wasn't the
   intention of the message sender.

   To strike a balance between these considerations, we adopt the
   convention that where significant loss of information may occur
   during conversion, or where an unmodified attachment is desired, the
   document can be sent as a multipart/alternative entity comprising the
   actual document and a standard MIME alternative.

Audio data formats

   MIME type name: audio

   MIME subtype name: microsoft-wave

Weatherley              DRAFT - expires 12/1/93                 [Page 2]
RFC DRAFT                                                      July 1993

   Required parameters: none

   Optional parameters: none

   Encoding considerations:

      Any transport encoding capable of accomodating binary data may be
      used.  The body part may be sent as part of a
      multipart/alternative entity with an audio/basic entity as the
      first part.  There can be significant loss of audio quality during
      conversion, hence the use of an alternative.  It is expected that
      this type will eventually be superceded by a richer standard MIME
      audio type.  Consult the current list of registered MIME Content-
      Types before implementing this type in new message composition

   Security considerations: none

   Published specification:

      The body part contains audio data conforming to the Microsoft Wave
      format, defined in chapter 8 of [MREF].

Image data formats

   No new image formats are registered by this memo.  The standard MIME
   image/gif format is capable of representing without loss the data
   contained in Microsoft Windows device independent bitmaps with
   between 1 and 8 bits per pixel.  Bitmaps with 24 bits per pixel can
   be represented with loss in the image/jpeg format.  The loss incurred
   is not expected to be significant, especially for real-life images.

   Microsoft Windows cursors, icons, and metafiles can be converted into
   bitmaps and then into image/gif or image/jpeg entities.  While some
   loss of information may occur, this is not expected to be

Application data formats

   This section describes a number of formats that are specific to
   programs that accompany releases of the Microsoft Windows graphical
   environment.  It is expected that additional formats will be added to
   this list over time.  The formats are naturally thought of as
   attachments rather than as message components, and there are
   currently no conversions without loss that can be performed to
   standard MIME types.

   MIME type name: application

Weatherley              DRAFT - expires 12/1/93                 [Page 3]
RFC DRAFT                                                      July 1993

   MIME subtype name: microsoft-group

   Required parameters: none

   Optional parameters: none

   Encoding considerations:

      Any transport capable of accomodating binary data may be used.
      This type should be sent as part of a multipart/alternative entity
      with a text/plain entity as the first part, which summarises the
      contents of the group file for readers that cannot understand the
      group file directly.

   Security considerations:

      Users should be wary of installing and using group files that
      originated with a remote source, since they may contain arbitrary
      Microsoft Windows and MS-DOS command-lines, that could wreak havoc
      with the user's machine.  User agents should at least warn the
      user before performing any automatic installation procedures.

   Published specification:

      The body part is a Microsoft Windows Program Manager group file.
      The file format is defined in chapter 5 of [SDK4].

   A group file contains data that the Program Manager uses to display
   icons of the applications in a group, start the applications in a
   group, and open related documents.

   Note that a group file can be very machine-specific, since it
   incorporates screen dimensions, icon color information, and execution
   paths that usually only apply to the machine on which the group file

   MIME type name: application

   MIME subtype name: microsoft-write

   Required parameters: none

   Optional parameters: none

   Encoding considerations:

      Any transport capable of accomodating binary data may be used.  It
      is possible to convert a Microsoft Write document (with loss) into

Weatherley              DRAFT - expires 12/1/93                 [Page 4]
RFC DRAFT                                                      July 1993

      a series of MIME body parts, typically using a mixture of the
      text/enriched [RFC-RICH] entities for the text portions, and other
      Content-Types for the embedded pictures and OLE (Object Linking
      and Embedding) objects.  If such a conversion is done, it should
      appear as the first part in a multipart/alternative entity with
      the Microsoft Write document as the second part.

      In many cases Microsoft Write documents will be attachments rather
      than inline message components, and also typically quite large.
      Hence, conversion should be done on user request rather than
      automatically.  If a Postscript version of the document is
      available, it may be used as one of the parts of a
      multipart/alternative entity, giving better output quality at the
      price of greater message size.

      Note that Microsoft Write documents under Windows 3.1 or later may
      contain linked OLE objects.  The data for these linked objects may
      not be available on the recipient's machine, so care should be
      taken to convert all linked objects into embedded objects before
      transmission.  This conversion can be done by either the user, the
      mail user agent, or the mail transfer agent.  The hexadecimal
      values of the first two bytes of a Microsoft Write file are 32 and
      BE respectively if the file contains OLE objects (either linked or
      embedded).  The values are 31 and BE otherwise.  For minimal
      compliance the user should be prompted for confirmation if a
      document contains any OLE objects.

   Security considerations:

      General MIME security considerations apply to Microsoft Write
      documents that contain OLE objects because object data is
      interpreted by external programs not within the direct control of
      MIME message viewers.

   Published specification:

      The body part is a document for the Microsoft Write wordprocessor
      distributed with Microsoft Windows.  The file format is defined in
      chapter 8 of [SDK4].

   MIME type name: application

   MIME subtype name: microsoft-calendar

   Required parameters: none

   Optional parameters: none

Weatherley              DRAFT - expires 12/1/93                 [Page 5]
RFC DRAFT                                                      July 1993

   Encoding considerations:

      Any transport capable of accomodating binary data may be used.
      This type should be sent as part of a multipart/alternative entity
      with a text/plain entity as the first part, which summarises the
      contents of the calendar file for readers that cannot understand
      the calendar file directly.

   Security considerations: none

   Published specification:

      The body part is a file for the Microsoft Windows Calendar
      program.  The file format is defined in chapter 9 of [SDK4].

Other formats: discussion

   The Microsoft Windows clipboard can save its data in a special
   clipboard file, described in chapter 2 of [SDK4].  Clipboard data is
   typically present in a number of alternative formats for the same
   information.  The clipboard file format was not assigned a Content-
   Type because its role in presenting multiple versions of the same
   data can be subsumed by the standard multipart/alternative MIME
   content type, and interoperability among MIME-compliant systems is
   increased by explicitly typing the clipboard data using MIME

   In a similar manner, instead of defining a Content-Type for the
   object linking and embedding (OLE) file format defined in [OLE], the
   data associated with an embedded or linked object should be extracted
   and tagged with an appropriate Content-Type.  As in the case of
   clipboard formats, this increases interoperability with MIME-
   compliant systems not based on Microsoft Windows.

   There is scope to separate the OLE file header information into a
   separate Content-Type and send this along with the associated object
   data in a multipart entity, but this has not been attempted as yet
   because OLE objects are rarely encountered outside of container
   documents such as Microsoft Write documents so very little would be
   gained in practice.

   A movie file format is described in [MREF] which was not assigned a
   Content-Type by this document because of ongoing standardisation
   efforts elsewhere to develop standard video formats.

Weatherley              DRAFT - expires 12/1/93                 [Page 6]
RFC DRAFT                                                      July 1993


   [MREF] Microsoft Corporation, "Microsoft Windows Multimedia
   Programmer's Reference", Microsoft Press, 1991, ISBN 1-55615-389-9.

   [OLE] Microsoft Corporation, "Object Linking and Embedding
   Programmer's Reference, Version 1", Microsoft Press, 1992, ISBN 1-

   [RFC-MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
   Mail Extensions): Mechanisms for Specifying and Describing the Format
   of Internet Message Bodies", RFC 1341, Bellcore, June, 1992.

   [RFC-RICH] Borenstein, N., "The text/enriched MIME Content-type",
   Working Draft, Bellcore, April, 1993.

   [SDK3] Microsoft Corporation, "Microsoft Windows 3.1 Programmer's
   Reference.  Volume 3: Messages, Structures and Macros", Microsoft
   Press, 1992, ISBN 1-55615-464-X.

   [SDK4] Microsoft Corporation, "Microsoft Windows 3.1 Programmer's
   Reference.  Volume 4: Resources", Microsoft Press, 1992, ISBN 1-

Security Considerations

   Security considerations were discussed above as they pertained to
   individual Content-Types.


   The author wishes to thank Nathaniel Borenstein for his valuable
   comments during the preparation of this draft.

Author's Address

   Rhys M. Weatherley
   Computer Science Department
   University of Queensland
   Queensland 4072

   Phone: +61 7 365 1657

Weatherley              DRAFT - expires 12/1/93                 [Page 7]