rfc1343.txt

RFC 的详细文档！

            Network Working Group               N. Borenstein, Bellcore
            Request for Comments: 1343                        June 1992

                        A User Agent Configuration Mechanism

                       For Multimedia Mail Format Information


          Status of This Memo

            This is an informational memo for  the  Internet  community,
            and  requests  discussion  and suggestions for improvements.
            This  memo  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,
            822,  934,  1049,  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-1341].  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 example, that if  the  content-type



            Borenstein                                          [Page 1]




            RFC 1343       Multimedia Mail Configuration       June 1992


            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.

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




            Borenstein                                          [Page 2]




            RFC 1343       Multimedia Mail Configuration       June 1992


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



            Borenstein                                          [Page 3]




            RFC 1343       Multimedia Mail Configuration       June 1992


            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.

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





            Borenstein                                          [Page 4]




            RFC 1343       Multimedia Mail Configuration       June 1992


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

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

                 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




            Borenstein                                          [Page 5]