A User Agent Configuration Mechanism For Multimedia Mail Format Information
RFC 1524

Document Type RFC - Informational (September 1993; Errata)
Was draft-borenstein-mailcap2 (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1524 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      N. Borenstein
Request for Comments: 1524                                      Bellcore
Category: Informational                                   September 1993

                  A User Agent Configuration Mechanism
                 For Multimedia Mail Format Information

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This memo suggests a file format to be used to inform multiple mail
   reading user agent programs about the locally-installed facilities
   for handling mail in various formats.  The mechanism is explicitly
   designed to work with mail systems based Internet mail as defined by
   RFC's 821 (STD 10), 822 (STD 11), 934, 1049 (STD 11), 1113, and the
   Multipurpose Internet Mail Extensions, known as MIME.  However, with
   some extensions it could probably be made to work for X.400-based
   mail systems as well.  The format and mechanism are proposed in a
   manner that is generally operating-system independent.  However,
   certain implementation details will inevitably reflect operating
   system differences, some of which will have to be handled in a
   uniform manner for each operating system.  This memo makes such
   situations explicit, and, in an appendix, suggests a standard
   behavior under the UNIX operating system.

Introduction

   The electronic mail world is in the midst of a transition from
   single-part text-only mail to multi-part, multi-media mail.  In
   support of this transition, various extensions to RFC 821 and RFC 822
   have been proposed and/or adopted, notably including MIME [RFC-1521].
   Various parties have demonstrated extremely high-functionality
   multimedia mail, but the problem of mail interchange between
   different user agents has been severe.  In general, only text
   messages have been shared between user agents that were not
   explicitly designed to work together.  This limitation is not
   compatible with a smooth transition to a multi-media mail world.

   One approach to this transition is to modify diverse sets of mail
   reading user agents so that, when they need to display mail of an
   unfamiliar (non-text) type, they consult an external file for
   information on how to display that file.  That file might say, for

Borenstein                                                      [Page 1]
RFC 1524             Multimedia Mail Configuration        September 1993

   example, that if the content-type of a message is "foo" it can be
   displayed to the user via the "displayfoo" program.

   This approach means that, with a one-time modification, a wide
   variety of mail reading programs can be given the ability to display
   a wide variety of types of message.  Moreover, extending the set of
   media types supported at a site becomes a simple matter of installing
   a binary and adding a single line to a configuration file.  Crucial
   to this scheme, however, is that all of the user agents agree on a
   common representation and source for the configuration file.  This
   memo proposes such a common representation.

Location of Configuration Information

   Each user agent must clearly obtain the configuration information
   from a common location, if the same information is to be used to
   configure all user agents.  However, individual users should be able
   to override or augment a site's configuration.  The configuration
   information should therefore be obtained from a designated set of
   locations.  The overall configuration will be obtained through the
   virtual concatenation of several individual configuration files known
   as mailcap files.  The configuration information will be obtained
   from the FIRST matching entry in a mailcap file, where "matching"
   depends on both a matching content-type specification, an entry
   containing sufficient information for the purposes of the application
   doing the searching, and the success of any test in the "test="
   field, if present.

   The precise location of the mailcap files is operating-system
   dependent.  A standard location for UNIX is specified in Appendix A.

Overall Format of a Mailcap File

   Each mailcap file consists of a set of entries that describe the
   proper handling of one media type at the local site.

   For example, one line might tell how to display a message in Group
   III fax format.  A mailcap file consists of a sequence of such
   individual entries, separated by newlines (according to the operating
   system's newline conventions). Blank lines and lines that start with
   the "#" character (ASCII 35) are considered comments, and are
   ignored.  Long entries may be continued on multiple lines if each
   non-terminal line ends with a backslash character ('\', ASCII 92), in
   which case the multiple lines are to be treated as a single mailcap
   entry.  Note that for such "continued" lines, the backslash must be
Show full document text