rfc1343.txt

RFC 的详细文档！

            RFC 1343       Multimedia Mail Configuration       June 1992


                      / "copiousoutput"   ; be interpreted as
                      / x-token           ; case-insensitive

                 fieldname =    / "compose"      ;Also all of these
                                / "composetyped" ;are case-insensitive.
                                / "print"
                                / "edit"
                                / "test"
                                / "x11-bitmap"
                                / "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.

          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 field, 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.)




            Borenstein                                          [Page 6]




            RFC 1343       Multimedia Mail Configuration       June 1992


            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  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

            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



            Borenstein                                          [Page 7]




            RFC 1343       Multimedia Mail Configuration       June 1992


            test program should return an  exit  code  of  zero  if  the
            condition is true, and a non-zero code otherwise.

            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



            Borenstein                                          [Page 8]




            RFC 1343       Multimedia Mail Configuration       June 1992


            in the  standard  manner  defined  by  MIME.   Because  such
            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


          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



            Borenstein                                          [Page 9]




            RFC 1343       Multimedia Mail Configuration       June 1992


            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", RFC  822,  UDEL, August, 1982.

            [RFC  1341]   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.

          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 10]