Network Working Group                                         J. PalmeRequest for Comments: 2557                    Stockholm University/KTHObsoletes: 2110                                             A. HopmannCategory: 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 ....................................  28Palme, et al.               Standards Track                     [Page 2]RFC 2557       MIME Encapsulation of Aggregate Documents      March 19991.  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 19992.  Terminology2.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 "&lt;" 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].