rfc2557.txt

RFC 的详细文档！

Network Working Group                                         J. Palme
Request for Comments: 2557                    Stockholm University/KTH
Obsoletes: 2110                                             A. Hopmann
Category: Standards Track                        Microsoft Corporation
                                                           N. Shelness
                                         Lotus Development Corporation
                                                            March 1999


    MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   HTML [RFC 1866] defines a powerful means of specifying multimedia
   documents. These multimedia documents consist of a text/html root
   resource (object) and other subsidiary resources (image, video clip,
   applet, etc. objects) referenced by Uniform Resource Identifiers
   (URIs) within the text/html root resource. When an HTML multimedia
   document is retrieved by a browser, each of these component resources
   is individually retrieved in real time from a location, and using a
   protocol, specified by each URI.

   In order to transfer a complete HTML multimedia document in a single
   e-mail message, it is necessary to: a) aggregate a text/html root
   resource and all of the subsidiary resources it references into a
   single composite message structure, and b) define a means by which
   URIs in the text/html root can reference subsidiary resources within
   that composite message structure.

   This document a) defines the use of a MIME multipart/related
   structure to aggregate a text/html root resource and the subsidiary
   resources it references, and b) specifies a MIME content-header
   (Content-Location) that allow URIs in a multipart/related text/html
   root body part to reference subsidiary resources in other body parts
   of the same multipart/related structure.




Palme, et al.               Standards Track                     [Page 1]

RFC 2557       MIME Encapsulation of Aggregate Documents      March 1999


   While initially designed to support e-mail transfer of complete
   multi-resource HTML multimedia documents, these conventions can also
   be employed to resources retrieved by other transfer protocols such
   as HTTP and FTP to retrieve a complete multi-resource HTML multimedia
   document in a single transfer or for storage and archiving of
   complete HTML-documents.

   Differences between this and a previous version of this standard,
   which was published as RFC 2110, are summarized in chapter 12.

Table of Contents

   1. Introduction .................................................   3
   2. Terminology  .................................................   4
      2.1 Conformance requirement terminology ......................   4
      2.2 Other terminology ........................................   4
   3. Overview .....................................................   6
   4. The Content-Location MIME Content Header .....................   6
      4.1 MIME content headers .....................................   6
      4.2 The Content-Location Header ..............................   7
      4.3 URIs of MHTML aggregates .................................   8
      4.4 Encoding and decoding of URIs in MIME header fields ......   8
   5. Base URIs for resolution of relative URIs ....................   9
   6. Sending documents without linked objects .....................  10
   7. Use of the Content-Type "multipart/related" ..................  11
   8. Usage of Links to Other Body Parts ...........................  13
      8.1 General principle ........................................  13
      8.2 Resolution of URIs in text/html body parts ...............  13
      8.3 Use of the Content-ID header and CID URLs ................  14
   9. Examples .....................................................  14
      9.1 Example of a HTML body without included linked objects ...  15
      9.2 Example with an absolute URI to an embedded GIF picture ..  15
      9.3 Example with relative URIs to embedded GIF pictures ......  16
      9.4 Example with a relative URI and no BASE available ........  17
      9.5 Example using CID URL and Content-ID header to an embedded
          GIF picture ..............................................  18
      9.6 Example showing permitted and forbidden references between
          nested body parts ........................................  19
   10. Character encoding issues and end-of-line issues ............  21
   11. Security Considerations .....................................  22
      11.1 Security considerations not related to caching ..........  22
      11.2 Security considerations related to caching ..............  23
   12. Differences as compared to the previous version of this
       proposed standard in RFC 2110 ...............................  24
   13. Acknowledgments .............................................  24
   14. References ..................................................  25
   15. Authors' Addresses ..........................................  27
   16. Full Copyright Statement ....................................  28



Palme, et al.               Standards Track                     [Page 2]

RFC 2557       MIME Encapsulation of Aggregate Documents      March 1999


1.  Introduction

   There are a number of document formats (Hypertext Markup Language
   [HTML2], Extended Markup Language [XML], Portable Document format
   [PDF] and Virtual Reality Markup Language [VRML]) that specify
   documents consisting of a root resource and a number of distinct
   subsidiary resources referenced by URIs within that root resource.
   There is an obvious need to be able to send such multi-resource
   documents in e-mail [SMTP], [RFC822] messages.

   The standard defined in this document specifies how to aggregate such
   multi-resource documents in MIME-formatted [MIME1 to MIME5] messages
   for precisely this purpose.

   While this specification was developed to satisfy the specific
   aggregation requirements of multi-resource HTML documents, it may
   also be applicable to other multi-resource document representations
   linked by URIs. While this is the case, there is no requirement that
   implementations claiming conformance to this standard be able to
   handle any URI linked document representations other than those whose
   root is HTML.

   This aggregation into a single message of a root resource and the
   subsidiary resources it references may also be applicable to
   resources retrieved by other protocols such as HTTP or FTP, or to the
   archiving of complete web pages as they appeared at a particular
   point in time.

   An informational RFC will be published as a supplement to this
   standard. The informational RFC will discuss implementation methods
   and some implementation problems. Implementers are strongly
   recommended to read this informational RFC when developing
   implementations of this standard. You can find it through URL
   http://www.dsv.su.se/~jpalme/ietf/mhtml.html.

   This standard specifies that body parts to be referenced can be
   identified either by a Content-ID (containing a Message-ID value) or
   by a Content-Location (containing an arbitrary URL). The reason why
   this standard does not only recommend the use of Content-ID-s is that
   it should be possible to forward existing web pages via e-mail
   without having to rewrite the source text of the web pages. Such
   rewriting has several disadvantages, one of them that security
   checksums will probably be invalidated.








Palme, et al.               Standards Track                     [Page 3]

RFC 2557       MIME Encapsulation of Aggregate Documents      March 1999


2.  Terminology

2.1 Conformance requirement terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [IETF-TERMS].

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST requirements for the protocols it implements. An
   implementation that satisfies all the MUST and all the SHOULD
   requirements for its protocols is said to be "unconditionally
   compliant"; one that satisfies all the MUST requirements but not all
   the SHOULD requirements for its protocols is said to be
   "conditionally compliant."

2.2 Other terminology

   Most of the terms used in this document are defined in other RFCs.

   Absolute URI,         See Relative Uniform Resource Locators
   AbsoluteURI           [RELURL].

   CID                   See Message/External Body Content-ID [MIDCID].

   Content-Base          This header was specified in RFC 2110, but has
                         been removed in this new version of the MHTML
                         standard.

   Content-ID            See Message/External Body Content-ID [MIDCID].

   Content-Location      MIME message or content part header with one
                         URI of the MIME message or content part body,
                         defined in section 4.2 below.

   Content-Transfer-     Conversion of a text into 7-bit octets as
   Encoding              specified in [MIME1] chapter 6.

   CR                    See [RFC822].

   CRLF                  See [RFC822].

   Displayed text        The text shown to the user reading a document
                         with a web browser. This may be different from
                         the HTML markup, see the definition of HTML
                         markup below.





Palme, et al.               Standards Track                     [Page 4]

RFC 2557       MIME Encapsulation of Aggregate Documents      March 1999


   Header                Field in a message or content heading
                         specifying the value of one attribute.

   Heading               Part of a message or content before the first
                         CRLFCRLF, containing formatted fields with
                         attributes of the message or content.

   HTML                  See HTML 2 specification [HTML2].

   HTML Aggregate        HTML objects together with some or all objects,
   objects               to which the HTML object contains hyperlinks,
                         directly or indirectly.

   HTML markup           A file containing HTML encodings as specified
                         in [HTML] which may be different from the
                         displayed text which a person using a web
                         browser sees. For example, the HTML markup may
                         contain "<" where the displayed text
                         contains the character "<".

   LF                    See [RFC822].

   MIC                   Message Integrity Codes, codes use to verify
                         that a message has not been modified.

   MIME                  See the MIME specifications [MIME1 to MIME5].

   MUA                   Messaging User Agent.

   PDF                   Portable Document Format, see [PDF].

   Relative URI,         See HTML 2 [HTML2] and RFC 1808 [RELURL].
   RelativeURI

   URI, absolute and     See RFC 1866 [HTML2].
   relative

   URL                   See RFC 1738 [URL].

   URL, relative         See Relative Uniform Resource Locators [RELURL].