rfc2110.txt

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

       etc...

    --boundary-example-1--

9.3 Example with relative URIs to an embedded GIF picture

      From: [e-mail]
      To: [e-mail]
      Subject: A simple example
      Mime-Version: 1.0
      Content-Base: http://www.ietf.cnri.reston.va.us
      Content-Type: Multipart/related; boundary="boundary-example-1";
                    type=Text/HTML




Palme & Hopmann             Standards Track                    [Page 13]

RFC 2110                         MHTML                        March 1997


      --boundary-example-1
         Content-Type: Text/HTML; charset=ISO-8859-1
         Content-Transfer-Encoding: QUOTED-PRINTABLE

         ... text of the HTML document, which might contain a hyperlink
         to the other body part, for example through a statement such as:
         <IMG SRC="/images/ietflogo.gif" ALT="IETF logo">
         Example of a copyright sign encoded with Quoted-Printable: =A9
         Example of a copyright sign mapped onto HTML markup: &#168;

      --boundary-example-1
         Content-Location: /images/ietflogo.gif
         Content-Type: IMAGE/GIF
         Content-Transfer-Encoding: BASE64

         R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
         NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
         etc...

      --boundary-example-1--

9.4 Example using CID URL and Content-ID header to an embedded GIF
   picture

      From: [e-mail]
      To: [e-mail]
      Subject: A simple example
      Mime-Version: 1.0
      Content-Type: Multipart/related; boundary="boundary-example-1";
                    type=Text/HTML

      --boundary-example-1
         Content-Type: Text/HTML; charset=US-ASCII

         ... text of the HTML document, which might contain a hyperlink
         to the other body part, for example through a statement such as:
         <IMG SRC="cid:foo4*[e-mail]" ALT="IETF logo">

      --boundary-example-1
         Content-ID: <foo4*[e-mail]>
         Content-Type: IMAGE/GIF
         Content-Transfer-Encoding: BASE64

         R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
         NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
         etc...

      --boundary-example-1--



Palme & Hopmann             Standards Track                    [Page 14]

RFC 2110                         MHTML                        March 1997


10. Content-Disposition header

   Note the specification in [REL] on the relations between Content-
   Disposition and multipart/related.

11. Character encoding issues and end-of-line issues

   For the encoding of characters in HTML documents and other text
   documents into a MIME-compatible octet stream, the following
   mechanisms are relevant:

   - HTML [HTML2, HTML-I18N] as an application of SGML [SGML] allows
     characters to be denoted by character entities as well as by numeric
     character references (e.g. "Latin small letter a with acute accent"
     may be represented by "&aacute;" or "&#225;") in the HTML markup.

   - HTML documents, in common with other documents of the MIME
     "Content-Type  text", can be represented in MIME using one of
     several character encodings. The MIME Content-Type "charset"
     parameter value indicates the particular encoding used. For the
     exact meaning and use of the "charset" parameter, please see
     [MIME-IMB section 4.2].

      Note that the "charset" parameter refers only to the MIME
      character encoding. For example, the string "&aacute;" can be sent
      in MIME with "charset=US-ASCII", while the raw character "Latin
      small letter a with acute accent" cannot.

   The above mechanisms are well defined and documented, and therefore
   not further explained here. In sending a message, all the above
   mentioned mechanisms MAY be used, and any mixture of them MAY occur
   when sending the document via e-mail. Receiving mail user agents
   (together with any Web browser they may use to display the document)
   MUST be capable of handling any combinations of these mechanisms.

   Also note that:

   - Any documents including HTML documents that contain octet values
     outside the 7-bit range need a content-transfer-encoding applied
     before transmission over certain transport protocols
     [MIME1, chapter 5].

   - The MIME standard [MIME1] requires that documents of "Content-Type:
     Text MUST be in canonical form before Content-Transfer-Encoding,
     i.e. that line breaks are encoded as CRLFs, not as bare CRs or bare
     LFs or something else. This is in contrast to [HTTP] where section
     3.6.1 allows other representations of line breaks.




Palme & Hopmann             Standards Track                    [Page 15]

RFC 2110                         MHTML                        March 1997


   Note that this might cause problems with integrity checks based on
   checksums, which might not be preserved when moving a document from
   the HTTP to the MIME environment. If a document has to be converted
   in such a way that a checksum integrity check becomes invalid, then
   this integrity check header SHOULD be removed from the document.

   Other sources of problems are Content-Encoding used in HTTP but not
   allowed in MIME, and charsets that are not able to represent line
   breaks as CRLF. A good overview of the differences between HTTP and
   MIME with regards to "Content-Type: Text" can be found in [HTTP],
   appendix C.

   If the original document has line breaks in the canonical form
   (CRLF), then the document SHOULD remain unconverted so that integrity
   check sums are not invalidated.

   A provider of HTML documents who wants his documents to be
   transferable via both HTTP and SMTP without invalidating checksum
   integrity checks, should always provide original documents in the
   canonical form with CRLF for line breaks.

   Some transport mechanisms may specify a default "charset" parameter
   if none is supplied [HTTP, MIME1]. Because the default differs for
   different mechanisms, when HTML is transferred through mail, the
   charset parameter SHOULD be included, rather than relying on the
   default.

12. Security Considerations

   Some Security Considerations include the potential to mail someone an
   object, and claim that it is represented by a particular URI (by
   giving it a Content-Location header). There can be no assurance that
   a WWW request for that same URI would normally result in that same
   object. It might be unsuitable to cache the data in such a way that
   the cached data can be used for retrieval of this URI from other
   messages or message parts than those included in the same message as
   the Content-Location header. Because of this problem, receiving User
   Agents SHOULD not cache this data in the same way that data that was
   retrieved through an HTTP or FTP request might be cached.

   URLs, especially File URLs, may in their name contain company-
   internal information, which may then inadvertently be revealed to
   recipients of documents containing such URLs.

   One way of implementing messages with linked body parts is to handle
   the linked body parts in a combined mail and WWW proxy server. The
   mail client is only given the start body part, which it passes to a
   web browser. This web browser requests the linked parts from the



Palme & Hopmann             Standards Track                    [Page 16]

RFC 2110                         MHTML                        March 1997


   proxy server. If this method is used, and if the combined server is
   used by more than one user, then methods must be employed to ensure
   that body parts of a message to one person is not retrievable by
   another person.  Use of passwords (also known as tickets or magic
   cookies) is one way of achieving this. Note that some caching WWW
   proxy servers may not distinguish between cached objects from e-mail
   and HTTP, which may be a security risk.

   In addition, by allowing people to mail aggregate objects, we are
   opening the door to other potential security problems that until now
   were only problems for WWW users. For example, some HTML documents
   now either themselves contain executable content (JavaScript) or
   contain links to executable content (The "INSERT" specification,
   Java). It would be exceedingly dangerous for a receiving User Agent
   to execute content received through a mail message without careful
   attention to restrictions on the capabilities of that executable
   content.

   Some WWW applications hide passwords and tickets (access tokens to
   information which may not be available to anyone) and other sensitive
   information in hidden fields in the web documents or in on-the-fly
   constructed URLs. If a person gets such a document, and forwards it
   via e-mail, the person may inadvertently disclose sensitive
   information.

13. Acknowledgments

   Harald T. Alvestrand, Richard Baker, Dave Crocker, Martin J. Duerst,
   Lewis Geer, Roy Fielding, Al Gilman, Paul Hoffman, Richard W.
   Jesmajian, Mark K. Joseph, Greg Herlihy, Valdis Kletnieks, Daniel
   LaLiberte, Ed Levinson, Jay Levitt, Albert Lunde, Larry Masinter,
   Keith Moore, Gavin Nicol, Pete Resnick, Jon Smirl, Einar Stefferud,
   Jamie Zawinski, Steve Zilles and several other people have helped us
   with preparing this document. I alone take responsibility for any
   errors which may still be in the document.
















Palme & Hopmann             Standards Track                    [Page 17]

RFC 2110                         MHTML                        March 1997


14. References

Ref.            Author, title
---------       --------------------------------------------------------

[CONDISP]       R. Troost, S. Dorner: "Communicating Presentation
                Information in Internet Messages: The
                Content-Disposition Header", RFC 1806, June 1995.

[HOSTS]         R. Braden (editor): "Requirements for Internet Hosts --
                Application and Support", STD-3, RFC 1123, October 1989.

[HTML-I18N]     F. Yergeau, G. Nicol, G. Adams, & M. Duerst:
                "Internationalization  of the Hypertext Markup
                Language". RFC 2070, January 1997.

[HTML2]         T. Berners-Lee, D. Connolly: "Hypertext Markup Language
                - 2.0", RFC 1866, November 1995.

[HTTP]          T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext
                Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.

[MD5]           R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321,
                April 1992.

[MIDCID]        E. Levinson: "Content-ID and Message-ID Uniform
                Resource Locators". RFC 2111, February 1997.

[MIME-IMB]      N. Freed & N. Borenstein: "Multipurpose Internet Mail
                Extensions (MIME) Part One: Format of Internet Message
                Bedies". RFC 2045, November 1996.

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

[MIME2]         N. Borenstein & N. Freed: "Multipurpose Internet Mail
                Extensions (MIME) Part Two: Media Types". RFC 2046,
                November 1996.

[NEWS]          M.R. Horton, R. Adams: "Standard for interchange of
                USENET messages", RFC 1036, December 1987.








Palme & Hopmann             Standards Track                    [Page 18]

RFC 2110                         MHTML                        March 1997


[PDF]           Bienz, T., Cohn, R. and Meehan, J.: "Portable Document
                Format Reference Manual, Version 1.1", Adboe Systems
                Inc.

[REL]           Edward Levinson: "The MIME Multipart/Related Content-
                Type". RFC 2112, February 1997.

[RELURL]        R. Fielding: "Relative Uniform Resource Locators", RFC
                1808, June 1995.

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

[SGML]          ISO 8879. Information Processing -- Text and Office  -
                Standard Generalized Markup Language (SGML),
                1986. <URL:http://www.iso.ch/cate/d16387.html>

[SMTP]          J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
                821, August 1982.

[URL]           T. Berners-Lee, L. Masinter, M. McCahill: "Uniform
                Resource Locators (URL)", RFC 1738, December 1994.

[URLBODY]       N. Freed and Keith Moore: "Definition of the URL MIME
                External-Body Access-Type", RFC 2017, October 1996.

15. Author's Address

   For contacting the editors, preferably write to Jacob Palme rather
   than Alex Hopmann.

   Jacob Palme                          Phone: [phone]
   Stockholm University and KTH         Fax: [phone]
   Electrum 230                         E-mail: [e-mail]
   S-164 40 Kista, Sweden

   Alex Hopmann                         E-mail: [e-mail]
   Microsoft Corporation
   3590 North First Street
   Suite 300
   San Jose
   CA 95134
   Working group chairman:

   Einar Stefferud <[e-mail]>






Palme & Hopmann             Standards Track                    [Page 19]