Internet DRAFT - draft-weatherley-microsoft-windows
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
Draft.
Distribution of this memo is unlimited.
Abstract
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.
Introduction
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
stated.
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
software.
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
significant.
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
originated.
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
conventions.
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
References
[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-
55615-539-5.
[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-
55615-494-1.
Security Considerations
Security considerations were discussed above as they pertained to
individual Content-Types.
Acknowledgements
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
Australia
Email: rhys@cs.uq.oz.au
Phone: +61 7 365 1657
Weatherley DRAFT - expires 12/1/93 [Page 7]
