rfc1524.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1524             Multimedia Mail Configuration        September 1993


Acknowledgements

   The author wishes to thank Malcolm Bjorn Gillies, Dan Heller, Olle
   Jaernefors, Keith Moore, Luc Rooijakkers, and the other members of
   the IETF task force on mail extensions for their comments on earlier
   versions of this draft.  If other acknowledgements were neglected,
   please let me know, as it was surely accidental.

Security Considerations

   Security issues are not discussed in this memo.  However, the use of
   the mechanisms described in this memo can make it easier for
   implementations to slip into the kind of security problems discussed
   in the MIME document.  Implementors and mailcap administrators should
   be aware of these security considerations, and in particular should
   exercise caution in the choice of programs to be listed in a mailcap
   file for automatic execution.

Author's Address

   Nathaniel S. Borenstein
   MRE 2D-296, Bellcore
   445 South St.
   Morristown, NJ 07962-1910

   EMail: [e-mail]
   Phone: [phone]
   Fax:  [phone]























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


Appendix A:  Implementation Details for UNIX

   Although this memo fully specifies a syntax for "mailcap" files, the
   semantics of the mailcap file are of necessity operating-system
   dependent in four respects.  In order to clarify the intent, and to
   promote a standard usage, this appendix proposes a UNIX semantics for
   these four cases.  If a mailcap mechanism is implemented on non-UNIX
   systems, similar semantic decisions should be made and published.

Location of the Mailcap File(s)

   For UNIX, a path search of mailcap files is specified.  The default
   path search is specified as including at least the following:

   $HOME/.mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap

   However, this path may itself be overridden by a path specified by
   the MAILCAPS environment variable.

Semantics of executable commands

   Several portions of a mailcap entry specify commands to be executed.
   In particular, the mandatory second fie ld, the view-command, takes a
   command to be executed, as do the optional print, edit, test, and
   compose fields.

   On a UNIX system, such commands will each be a full shell command
   line, including the path name for a program and its arguments.
   (Because of differences in shells and the implementation and behavior
   of the same shell from one system to another, it is specified that
   the command line be intended as input to the Bourne shell, i.e., that
   it is implicitly preceded by "/bin/sh -c " on the command line.)

   The two characters "%s", if used, will be replaced by the name of a
   file for the actual mail body data.  In the case of the edit adn
   view-command, the body part will be passed to this command as
   standard input unless one or more instances of "%s" appear in the
   view-command, in which case %s will be replaced by the name of a file
   containing the body part, a file which may have to be created before
   the view-command program is executed.  (Such files cannot be presumed
   to continue to exist after the view-command program exits.  Thus a
   view-command that wishes to exit and continue processing in the
   background should take care to save the data first.)  In the case of
   the compose and composetyped commands, %s should be replaced by the
   name of a file to which the composed data should be written by the
   programs named in the compose or composedtyped commands.  Thus, the
   calling program will look in that file later in order to retrieve the
   composed data. If %s does not appear in the compose or composetyped



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


   commands, then the composed data will be assumed to be written by the
   composing programs to standard output.

   Furthermore, any occurrence of "%t" will be replaced by the content-
   type and subtype specification.  (That is, if the content-type is
   "text/plain", then %t will be replaced by "text/plain".)  A literal %
   character may be quoted as \%.  Finally, named parameters from the
   Content-type field may be placed in the command execution line using
   "%{" followed by the parameter name and a closing "}" character.  The
   entire parameter should appear as a single command line argument,
   regardless of embedded spaces.  Thus, if the message has a Content-
   type line of:

         Content-type:  multipart/mixed; boundary=42

   and the mailcap file has a line of:

         multipart/*; /usr/local/bin/showmulti \
           %t %{boundary}

   then the equivalent  of  the  following  command  should  be
   executed:

        /usr/local/bin/showmulti multipart/mixed 42

   If the content-type is "multipart" (any subtype), then the two
   characters "%n" will be replaced by an integer giving the number of
   sub-parts within the multipart entity.  Also, the two characters "%F"
   will be replaced by a set of arguments, twice as many arguments as
   the number of sub-parts, consisting of alternating content-types and
   file names for each part in turn.  Thus if multipart entity has three
   parts, "%F" will be replaced by the equivalent of "content-type1
   file-name1 content-type2 file-name2 content-type3 file-name3".

Semantics of the "test" field

   The "test" field specifies a program to be used to test whether or
   not the current mailcap line applies.  This can be used, for example,
   to have a mailcap line that only applies if the X window system is
   running, or if the user is running on a SPARCstation with a
   /dev/audio.  The value of the "test" field is a program to run to
   test such a condition.  The precise program to run and arguments to
   give it are determined as specified in the previous section.  The
   test program should return an exit code of zero if the condition is
   true, and a non-zero code otherwise.






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


Semantics of the "compose" field

   On UNIX, the composing program is expected to produce a data stream
   for such a body part as its standard output.  The program will be
   executed with the command line arguments determined as specified
   above.  The data returned via its standard output will be given a
   Content-Type field that has no supplementary parameters.  For
   example, the following mailcap entry:

        audio/basic; /usr/local/bin/showaudio %t
          compose = /usr/local/bin/recordaudio

   would result in tagging the data composed by the "recordaudio"
   program as:

        Content-Type: audio/basic

   If this is unacceptable -- for example, in the case of multipart mail
   a "boundary" parameter is required -- then the "compose" field cannot
   be used.  Instead, the "composetyped" field should be used in the
   mailcap file.

Semantics of the "composetyped" field

   The "composetyped" filed is much like the "compose" field, except
   that it names a composition program that produces, not raw data, but
   data that includes a MIME-conformant type specification.  The program
   will be executed with the command line arguments determined as
   specified above.  The data returned via its standard output must
   begin with a Content-Type header, followed optionally by other
   Content-* headers, and then by a blank line and the data.  For
   example, the following mailcap entry:

        multipart/mixed; /usr/local/bin/showmulti %t \
          %{boundary}; \
          composetyped = /usr/local/bin/makemulti

   would result in executing the "makemulti" program, which would be
   expected to begin its output with a line of the form:

        Content-Type: multipart/mixed; boundary=foobar

   Note that a composition program need not encode binary data in base64
   or quoted-printable. It remains the responsibility of the software
   calling the composition program to encode such data as necessary.
   However, if a composing program does encode data, which is not
   encouraged, it should announce that fact using a Content-Transfer-
   Encoding header in the standard manner defined by MIME.  Because such



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


   encodings must be announced by such a header, they are an option only
   for composetyped programs, not for compose programs.

Appendix B: Sample Mailcap File

   The following is an example of a mailcap file for UNIX that
   demonstrates most of the syntax above.  It contains explanatory
   comments where necessary.

         # Mailcap file for Bellcore lab 214.
         #
         # The next line sends "richtext" to the richtext
         program
         text/richtext; richtext %s; copiousoutput
         #
         # Next, basic u-law audio
         audio/*; showaudio; test=/usr/local/bin/hasaudio
         #
         # Next, use the xview program to handle several image
         formats
         image/*; xview %s; test=/usr/local/bin/RunningX
         #
         # The ATOMICMAIL interpreter uses curses, so needs a
         terminal
         application/atomicmail; /usr/local/bin/atomicmail %s; \
             needsterminal
         #
         # The next line handles Andrew format,
         #   if ez and ezview are installed
         x-be2; /usr/andrew/bin/ezview %s; \
            print=/usr/andrew/bin/ezprint %s ; \
            compose=/usr/andrew/bin/ez -d %s \;
            edit=/usr/andrew/bin/ez -d %s; \;
            copiousoutput
         #
         # The next silly example demonstrates the use of
         quoting
         application/*; echo "This is \"%t\" but \
            is 50 \% Greek to me" \; cat %s; copiousoutput












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


Appendix C:  A Note on Format Translation

   It has been suggested that another function of a mailcap-like
   mechanism might be to specify the locally available tools for
   document format translation.  For example, the file could designate a
   program for translating from format A to format B, another for
   translating from format B to format C, and finally a mechanism for
   displaying format C.  Although this mechanism would be somewhat
   richer than the current mailcap file, and might conceivably also have
   utility at the message transport layer, it significantly complicates
   the processing effort necessary for a user agent that simply wants to
   display a message in format A.  Using the current, simpler, mailcap
   scheme, a single line could tell such a user agent to display A-
   format mail using a pipeline of translators and the C-format viewer.
   This memo resists the temptation to complicate the necessary
   processing for a user agent to accomplish this task.  Using the
   mailcap format defined here, it is only necessary to find the correct
   single line in a mailcap file, and to execute the command given in
   that line.

References

     [RFC-822] Crocker, D., "Standard for the format of ARPA Internet
     text messages", STD 11, RFC 822, UDEL, August 1982.

     [RFC-1521] Borenstein, N., and N.  Freed, "MIME (Multipurpose
     Internet Mail Extensions) Part One: Mechanisms for Specifying and
     Describing the Format of Internet Message Bodies", RFC 1521,
     Bellcore, Innosoft, September 1993.






















Borenstein                                                     [Page 12]