rfc1344.txt

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

            will  be encountered "downstream",  but intelligent  guesses
            are often possible.  Moreover, an IETF working group on SMTP
            extensions has proposed augmenting SMTP with a  "SIZE"  verb
            that   would   facilitate  this  process,  thereby  possibly
            requiring  fragmentation   on   the   fly   during   message
            transmission.

            Note also that fragmentation or reassembly might  reasonably
            be  performed,  in  differing  circumstances,  by either the
            sending or receiving gateway  systems,  depending  on  which
            system knew more about the capabilities of the other.

          Using or Removing External-Body Pointers

            Another MIME type oriented to extremely  large  messages  is
            the  "message/external-body" type.  In this type of message,
            all or part of the body data is not included in  the  actual
            message  itself.   Instead,  the  Content-Type  header field
            includes information that tells how the  body  data  can  be
            retrieved -- either via a file system, via anonymous ftp, or
            via other mechanisms.

            The message/external-body type provides  a  new  option  for
            mail  transport  services  that  wishes  to optimize the way
            bandwidth resources are used in a  given  environment.   For
            example, the basic use of message/external-body is to reduce
            bandwidth in email traffic. However, when  email  crosses  a



            Borenstein                                          [Page 5]




            RFC 1344           MIME and Mail Gateways          June 1992


            slow and expensive boundary -- e.g., a satellite link across
            the Pacific -- it might make  sense  to  retrieve  the  data
            itself  and  transform  the external-body reference into the
            actual data.  Alternately, it might make sense to  copy  the
            data  itself  to  a  new  location,  closer  to  the message
            recipients, and  change  the  location  pointed  to  in  the
            message.    Because   the  external-body  specification  can
            include an expiration date, message transport  services  can
            trade  off  storage  and  bandwidth  capabilities  to try to
            optimize  the  overall  use  of  resources  for  very  large
            messages.

            Such behaviors by a  gateway  require  careful  analysis  of
            cost/benefit   tradeoffs  and  would be a dramatic departure
            from  typical  mail  transport   services.    However,   the
            potential  benefits  are quite significant, so that such the
            appropriate use of these service options should be explored.

            For example, the following message includes PostScript  data
            by external reference:

                 From:  Nathaniel Borenstein <[e-mail]>
                 To: Ned Freed <[e-mail]>
                 Subject: The latest MIME draft
                 Content-Type: message/external-body;
                      name="BodyFormats.ps";
                      site="thumper.bellcore.com";
                      access-type=ANON-FTP;
                      directory="pub";
                      mode="image";
                      expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

                 Content-type: application/postscript

            A gateway to Australia might choose to copy the file  to  an
            Australian  FTP archive, changing the relevant parameters on
            the Content-type header field.  Alternately, it might choose
            simply  to  transform  the message into one in which all the
            data were included:

                 From:  Nathaniel Borenstein <[e-mail]>
                 To: Ned Freed <[e-mail]>
                 Subject: The latest MIME draft
                 Content-type: application/postscript

                 %!PS-Adobe-1.0
                 %%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
                 274,4270,9938586,21462)
                 etc...

            This is an example which suggests both the benefits and  the
            dangers.  There  is considerable benefit to having a copy of
            the data immediately  available,   but  there  also  may  be
            considerable  expense involved in transporting it to all  of



            Borenstein                                          [Page 6]




            RFC 1344           MIME and Mail Gateways          June 1992


            a the members of a list, if only a few  will  use  the  data
            anytime soon.

            Alternatively, instead of replacing an external-body message
            with  its real contents, it might make sense to transform it
            into a "multipart/alternative" message containing  both  the
            external  body  reference  and  the  expanded version.  This
            means that only the external body part can be  forwarded  if
            desired,  and  the recipient doesn't lose the information as
            to where the data was fetched from, if they want to fetch an
            up-to-date version in the future.  Such information could be
            represented, in MIME, in the following form:

                 From:  Nathaniel Borenstein <[e-mail]>
                 To: Ned Freed <[e-mail]>
                 Subject: The latest MIME draft
                 Content-type: multipart/alternative; boundary=foo

                 --foo
                 Content-Type: message/external-body;
                      name="BodyFormats.ps";
                      site="thumper.bellcore.com";
                      access-type=ANON-FTP;
                      directory="pub";
                      mode="image";
                      expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

                 Content-type: application/postscript
                 --foo
                 Content-type: application/postscript

                 %!PS-Adobe-1.0
                 %%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
                 274,4270,9938586,21462)
                 etc...
                 --foo--

            Similarly for the case where a message is copied to a  local
            FTP  site,  one  could  offer two external body parts as the
            alternatives, allowing the user agent to  choose  which  FTP
            site is preferred.

          Image and other Format Conversions

            MIME currently defines  two  image  formats,  image/gif  and
            image/jpeg.   The  former  is  much more convenient for many
            users, and can be displayed more quickly  on  many  systems.
            The  latter  is  a  much  more  compact  representation, and
            therfore places less stress on mail transport facilities.

            Message  transport  services  can  optimize  both  transport
            bandwidth  and  user  convenience by intelligent translation
            between these formats (and other formats that might be added
            later).   When  a message of type image/gif is submitted for



            Borenstein                                          [Page 7]




            RFC 1344           MIME and Mail Gateways          June 1992


            long-haul delivery, it might  reasonably  be  translated  to
            image/jpeg.   Conversely,  when  image/jpeg data is received
            for  final  delivery  on  a  system  with  adequate  storage
            resources,  it  might  be  translated  to  image/gif for the
            convenience of the recipient.   Software  to  perform  these
            translations  is  widely  available.   It  should  be noted,
            however,  that  performance  of  such  conversions  presumes
            support for the new format by the recipient.

            Although MIME currently only defines one audio format,  more
            are  likely  to  be  defined and registered with IANA in the
            future.  In that case, similar format conversion  facilities
            might be appropriate for audio.

            If format conversion is done,  it  is  STRONGLY  RECOMMENDED
            that some kind of trace information (probably in the form of
            a Received header field) should be added  to  a  message  to
            document the conversion that has been performed.

            Some people have expressed concerns,  or  even  the  opinion
            that  conversions  should  never be done.  To accomodate the
            desires of those who dislike the idea  of  automatic  format
            conversion.   For  this  reason,  it  is suggested that such
            transformations be generally restricted to  gateways  rather
            than  general  message transport services, and that services
            which perform such conversions  should  be  sensitive  to  a
            header field that indicates that the sender does not wish to
            have any such conversions performed.  A suggested value  for
            this header field is:

            Content-Conversion: prohibited

            User agents that wish to explicitly indicate  a  willingness
            for such conversions to be performed may use:

            Content-Conversion: permitted

            However,  this  will  be  the  default  assumption  of  many
            gateways,  so  this  header field is not strictly necessary.
            It also should be noted  that  such  control  of  conversion
            would only be available to the sender, rather than to any of
            the recipients.















            Borenstein                                          [Page 8]




            RFC 1344           MIME and Mail Gateways          June 1992


          Robust Encoding of Data

            In addition to all the  reasons  given  above  for  possible
            transformation  of  body data, it will sometimes be the case
            that a gateway can tell that the body data, as  given,  will
            not  robustly  survive  the  next  step  of  transport.  For
            example, mail crossing an ASCII-to-EBCDIC gateway will  lose
            information  if certain characters are used.  In such cases,
            a gateway can make the data more robust simply  by  applying
            one of the MIME Content-Transfer-Encoding algorithms (base64
            or quoted-printable) to the body or body  part.   This  will
            generally  be  a  loss-less transformation, but care must be
            taken  to  ensure  that  the  resulting  message  is   MIME-
            conformant  if  the inital message was not.  (For example, a
            MIME-Version header field may need to be added.)

          User-oriented concerns

            If a gateway is going to perform major transformations on  a
            mail  message,  such as translating image formats or mapping
            between included data and external-reference data, it  seems
            inevitable that there will be situations in which users will
            object to these transformations.  This is, in large part, an
            implementation  issue,  but  it  seems  advisable,  wherever
            possible, to provide a mechanism whereby users can  specify,
            to  the  transport  system,  whether  or  not they want such
            services performed automatically on their behalf. The use of
            the  "Content-Conversion"  header field, as mentioned above,
            is suggested for this purpose, since it  it  least  provides
            some control by the sender, if not the recipient.

          References

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

          Security Considerations

            Security issues are not  discussed in this memo.

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