rfc1524.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 675 行 · 第 1/2 页

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
   the last character on the line to be continued.





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


   Thus the overall format of a mailcap file is given, in the modified
   BNF of RFC 822, as:

         Mailcap-File = *Mailcap-Line

         Mailcap-Line = Comment / Mailcap-Entry

         Comment = NEWLINE  /  "#" *CHAR NEWLINE

         NEWLINE = <newline as defined by OS convention>

   Note that the above specification implies that comments must appear
   on lines all to themselves, with a "#" character as the first
   character on each comment line.

Format of a Mailcap Entry

   Each mailcap entry consists of a number of fields, separated by
   semi-colons.  The first two fields are required, and must occur in
   the specified order.  The remaining fields are optional, and may
   appear in any order.

   The first field is the content-type, which indicates the type of data
   this mailcap entry describes how to handle.  It is to be matched
   against the type/subtype specification in the "Content-Type" header
   field of an Internet mail message.  If the subtype is specified as
   "*", it is intended to match all subtypes of the named content-type.

   The second field, view-command, is a specification of how the message
   or body part can be viewed at the local site.  Although the syntax of
   this field is fully specified, the semantics of program execution are
   necessarily somewhat operating system dependent.  UNIX semantics are
   given in Appendix A.

   The optional fields, which may be given in any order, are as follows:

   -- The "compose" field may be used to specify a program that can be
      used to compose a new body or body part in the given format.  Its
      intended use is to support mail composing agents that support the
      composition of multiple types of mail using external composing
      agents.  As with the view-command, the semantics of program
      execution are operating system dependent, with UNIX semantics
      specified in Appendix A.  The result of the composing program may
      be data that is not yet suitable for mail transport -- that is, a
      Content-Transfer-Encoding may need to be applied to the data.

   -- The "composetyped" field is similar to the "compose" field, but is
      to be used when the composing program needs to specify the



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


      Content-type header field to be applied to the composed data.  The
      "compose" field is simpler, and is preferred for use with existing
      (non-mail-oriented) programs for composing data in a given format.
      The "composetyped" field is necessary when the Content-type
      information must include auxilliary parameters, and the
      composition program must then know enough about mail formats to
      produce output that includes the mail type information.

   -- The "edit" field may be used to specify a program that can be used
      to edit a body or body part in the given format.  In many cases,
      it may be identical in content to the "compose" field, and shares
      the operating-system dependent semantics for program execution.

   -- The "print" field may be used to specify a program that can be
      used to print a message or body part in the given format.  As with
      the view-command, the semantics of program execution are operating
      system dependent, with UNIX semantics specified in Appendix A.

   -- The "test" field may be used to test some external condition
      (e.g., the machine architecture, or the window system in use) to
      determine whether or not the mailcap line applies.  It specifies a
      program to be run to test some condition.  The semantics of
      execution and of the value returned by the test program are
      operating system dependent, with UNIX semantics specified in
      Appendix A.  If the test fails, a subsequent mailcap entry should
      be sought.  Multiple test fields are not permitted -- since a test
      can call a program, it can already be arbitrarily complex.

   -- The "needsterminal" field indicates that the view-command must be
      run on an interactive terminal.  This is needed to inform window-
      oriented user agents that an interactive terminal is needed.  (The
      decision is not left exclusively to the view-command because in
      some circumstances it may not be possible for such programs to
      tell whether or not they are on interactive terminals.)  The
      needsterminal command should be assumed to apply to the compose
      and edit commands, too, if they exist.  Note that this is NOT a
      test -- it is a requirement for the environment in which the
      program will be executed, and should typically cause the creation
      of a terminal window when not executed on either a real terminal
      or a terminal window.

   -- The "copiousoutput" field indicates that the output from the
      view-command will be an extended stream of output, and is to be
      interpreted as advice to the UA (User Agent mail-reading program)
      that the output should be either paged or made scrollable. Note
      that it is probably a mistake if needsterminal and copiousoutput
      are both specified.




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


   -- The "description" field simply provides a textual description,
      optionally quoted, that describes the type of data, to be used
      optionally by mail readers that wish to describe the data before
      offering to display it.

   -- The "textualnewlines" field, if set to any non-zero value,
      indicates that this type of data is line-oriented and that, if
      encoded in base64, all newlines should be converted to canonical
      form (CRLF) before encoding, and will be in that form after
      decoding.  In general, this field is needed only if there is
      line-oriented data of some type other than text/* or non-line-
      oriented data that is a subtype of text.

   -- The "x11-bitmap" field names a file, in X11 bitmap (xbm) format,
      which points to an appropriate icon to be used to visually denote
      the presence of this kind of data.

   -- The "nametemplate" field gives a file name format, in which %s
      will be replaced by a short unique string to give the name of the
      temporary file to be passed to the viewing command.  This is only
      expected to be relevant in environments where filename extensions
      are meaningful, e.g., one coulld specify that a GIF file being
      passed to a gif viewer should have a name eding in ".gif" by using
      "nametemplate=%s.gif".

   Any other fields beginning with "x-" may be included for local or
   mailer-specific extensions of this format.  Implementations should
   simply ignore all such unrecognized fields to permit such extensions,
   some of which might be standardized in a future version of this
   document.

   Some of the fields above, such as "needsterminal", apply to the
   actions of the view-command, edit-command, and compose-command,
   alike.  In some unusual cases, this may not be desirable, but
   differentiation can be accomplished via separate mailcap entries,
   taking advantage of the fact that subsequent mailcap entries are
   searched if an earlier mailcap entry does not provide enough
   information:

       application/postscript; ps-to-terminal %s;\ needsterminal
       application/postscript; ps-to-terminal %s; \compose=idraw %s

   In RFC 822 modified BNF, the following grammar describes a mailcap
   entry:







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


         Mailcap-Entry = typefield ; view-command
                             [";" 1#field]

         typefield = propertype / implicit-wild

         propertype = type "/" wildsubtype

         implicitwild = type

         wildsubtype = subtype / "*"

         view-command = mtext

         mtext = *mchar

         mchar = schar / qchar

         schar = * <any CHAR except ";","\", and CTLS>

         qchar = "\" CHAR ; may quote any char

         field = flag / namedfield

         namedfield = fieldname "=" mtext

         flag = "needsterminal"   ; All these literals are to
              / "copiousoutput"   ; be interpreted as
              / x-token           ; case-insensitive

         fieldname =    / "compose"      ;Also all of these
                        / "composetyped" ;are case-insensitive.
                        / "print"
                        / "edit"
                        / "test"
                        / "x11-bitmap"
                        / "textualnewlines"
                        / "description"
                        / x-token

   Note that "type", "subtype", and "x-token" are defined in MIME.  Note
   also that while the definition of "schar" includes the percent sign,
   "%", this character has a special meaning in at least the UNIX
   semantics, and will therefore need to be quoted as a qchar to be used
   literally.







Borenstein                                                      [Page 6]