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.
AbstractHTML [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.
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. 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
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.
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." 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.
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]. VRML See Virtual Reality Markup Language [VRML].
ABNF]: quoted-pair = ("\" text) text = %d1-9 / ; Characters excluding CR and LF %d11-12 / %d14-127 WSP = SP / HTAB ; Whitespace characters
FWS = ([*WSP CRLF] 1*WSP) ; Folding white-space ctext = NO-WS-CTL / ; Non-white-space controls %d33-39 / ; The rest of the US-ASCII %d42-91 / ; characters not including "(", %d93-127 ; ")", or "\" comment = "(" *([FWS] (ctext / quoted-pair / comment)) [FWS] ")" CFWS = *([FWS] comment) (([FWS] comment) / FWS) content-location = "Content-Location:" [CFWS] URI [CFWS] URI = absoluteURI | relativeURI where URI is restricted to the syntax for URLs as defined in Uniform Resource Locators [URL] until IETF specifies other kinds of URIs. MIME1]) and, in Message headings, a Message-ID (as specified in [RFC822]). All of these constitute different, equally valid body part labels, and any of them may be used to satisfy a reference to a body part. Multiple Content-Location header fields in the same message heading are not allowed.
Example of a multipart/related structure containing body parts with both Content-Location and Content-ID labels: Content-Type: multipart/related; boundary="boundary-example"; type="text/html" --boundary-example Content-Type: text/html; charset="US-ASCII" ... ... <IMG SRC="fiction1/fiction2"> ... ... ... ... <IMG SRC="cid:firstname.lastname@example.org"> ... ... --boundary-example Content-Type: image/gif Content-ID: <email@example.com> Content-Location: fiction1/fiction2 --boundary-example Content-Type: image/gif Content-ID: <firstname.lastname@example.org> Content-Location: fiction1/fiction3 --boundary-example-- RFC 822 header, either because the URI itself has an incorrect syntax according to [URL] or the URI syntax standard
has been changed to allow characters not previously allowed in MIME headers. These URIs cannot be sent directly in a message header. If such a URI occurs, all spaces and other illegal characters in it must be encoded using one of the methods described in [MIME3] section 4. This encoding MUST only be done in the header, not in the HTML text. Receiving clients MUST decode the [MIME3] encoding in the heading before comparing URIs in body text to URIs in Content-Location headers. The charset parameter value "US-ASCII" SHOULD be used if the URI contains no octets outside of the 7-bit range. If such octets are present, the correct charset parameter value (derived e.g. from information about the HTML document the URI was found in) SHOULD be used. If this cannot be safely established, the value "UNKNOWN-8BIT" [RFC 1428] MUST be used. Note, that for the matching of URIs in text/html body parts to URIs in Content-Location headers, the value of the charset parameter is irrelevant, but that it may be relevant for other purposes, and that incorrect labeling MUST, therefore, be avoided. Warning: Irrelevance of the charset parameter may not be true in the future, if different character encodings of the same non-English filename are used in HTML. URLBODY] section 3.1. RELURL]. In order to determine this base URI, the first-applicable method in the following list applies.
(a) There is a base specification inside the MIME body part containing the relative URI which resolves relative URIs into absolute URIs. For example, HTML provides the BASE element for this purpose. (b) There is a Content-Location header in the immediately surrounding heading of the body part and it contains an absolute URI. This URI can serve as a base in the same way as a requested URI can serve as a base for relative URIs within a file retrieved via HTTP [HTTP]. (c) If necessary, step (b) can be repeated recursively to find a suitable Content-Location header in a surrounding multi-part or message heading. (d) If the MIME object is returned in a HTTP response, use the URI used to initiate the request (e) When the methods above do not yield an absolute URI, a base URL of "thismessage:/" MUST be employed. This base URL has been defined for the sole purpose of resolving relative references within a multipart/related structure when no other base URI is specified. This is also described in other words in section 8.2 below.
HTML2]) refer, then this whole set of body parts (referring body parts and referred-to body parts) SHOULD be sent within a multipart/related structure as defined in [REL]. Even though headers can occur in a message that lacks an associated multipart/related structure, this standard only covers their use for resolution of URIs between body parts inside a multipart/related structure. This standard does cover the case where a resource in a nested multipart/related structure contains URIs that reference MIME body parts in another multipart/related structure, in which it is enclosed. This standard does not cover the case where a resource in a multipart/related structure contains URIs that reference MIME body parts in another parallel or nested multipart/related structure, or in another MIME message, even if methods similar to those described in this standard are used. Implementers who employ such URIs are warned that receiving agents implementing this standard may not be able to process such references. When the start body part of a multipart/related structure is an atomic object, such as a text/html resource, it SHOULD be employed as the root resource of that multipart/related structure. When the start body part of a multipart/related structure is a multipart/alternative structure, and that structure contains at least one alternative body part which is a suitable atomic object, such as a text/html resource, then that body part SHOULD be employed as the root resource of the aggregate document. Implementers are warned, however, that some receiving agents treat multipart/alternative as if it had been multipart/mixed (even though MIME [MIME1] requires support for multipart/alternative). [REL] specifies that a type parameter is mandatory in a "Content- Type: multipart/related" header, and requires that it be employed to specify the type of the multipart/related start object. Thus, the type parameter value shall be "multipart/alternative", when the start part is of "Content-type multipart/alternative", even if the actual root resource is of type "text/html". In addition, if the multipart/related start object is not the first body part in a multipart/related structure, [REL] further requires that its Content-ID MUST be specified as the value of a start parameter in the "Content-Type: multipart/related" header.
When rendering a resource in a multipart/related structure, URI references within that resource can be satisfied by body parts within the same multipart/related structure (see section 8.2 below). This is useful: (a) For those recipients who only have email but not full Internet access. (b) For those recipients who for other reasons, such as firewalls or the use of company-internal links, cannot retrieve URI referenced resources via URI specified protocols. Note, that this means that you can, via e-mail, send text/html objects which includes URIs which the recipient cannot resolve via HTTP or other connectivity-requiring URIs. (c) To send a document whose content is preserved even if the resources to which embedded URIs refer are later changed or deleted. (d) For resources which are not available for protocol based retrieval. (e) To speed up access. When a sending MUA sends objects which were retrieved from the WWW, it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs into some other URI form prior to transmitting them. This will allow the receiving MUA to both verify MICs included with the message, as well as verify the documents against their WWW counterpoints, if this is appropriate. In certain cases this will not work - for example, if a resource contains URIs as parameters to objects and applets. In such a case, it might be better to rewrite the document before sending it. This problem is discussed in more detail in the informational RFC which will be published as a supplement to this standard. Within a multipart/related structure, each body part MUST have, if assigned, a different Content-ID header value and a Content-Location header field values which resolve to a different URI. Two body parts in the same multipart/related structure can have the same relative Content-Location header value, only if when resolved to absolute URIs they become different.
HTML2]. New elements and attributes with this property are proposed in the ongoing development of HTML (examples: applet, frame, profile, OBJECT, classid, codebase, data, SCRIPT). A sender might also want to send a set of HTML documents which the reader can traverse, and which are related with the attribute href of the A element. If a user retrieves and displays a web page formed from a text/html resource, and the subsidiary resources it references, and merely saves the text/html resource, that user may not at a later time be able to retrieve and display the web page as it appeared when saved. The format described in this standard can be used to archive and retrieve all of the resources required to display the web page, as it originally appeared at a certain moment of time, in one aggregate file. In order to send or store complete such messages, there is a need to specify how a URI in one body part can reference a resource in another body part. URLBODY]. Do NOT however translate character encodings of the kind described in [URL]. Example: Do not transform "a%2eb/c%20d" into "a/b/c d". (b) Remove all MIME encodings, such as content-transfer encoding and header encodings as defined in MIME part 3 [MIME3] Do NOT however translate character encodings of the kind described in [URL]. Example: Do not transform "a%2eb/c%20d" into "a/b/c d". (c) Try to resolve all relative URIs in the HTML content and in Content-Location headers using the procedure described in chapter 5 above. The result of this resolution can be an absolute URI, or an absolute URI with the base "thismessage:/" as specified in
chapter 5. (d) For each referencing URI in a text/html body part, compare the value of the referencing URI after resolution as described in (a) and (b), with the URI derived from Content-ID and Content- Location headers for other body parts within the same or a surrounding Multipart/related structure. If the strings are identical, octet by octet, then the referencing URI references that body part. This comparison will only succeed if the two URIs are identical. This means that if one of the two URIs to be compared was a fictitious absolute URI with the base "thismessage:/", the other must also be such a fictitious absolute URI, and not resolvable to a real absolute URI. (e) If (d) fails, try to retrieve the URI referenced resource hyperlink through ordinary Internet lookup. Resolution of URIs of the URL-types "mid" or "cid" to other content-parts, outside the same multipart/related structure, or in other separately sent messages, is not covered by this standard, and is thus neither encouraged nor forbidden. URL] and [MIDCID] are used to reference other body parts in an MHTML multipart/related structure, they MUST only be matched against Content-ID header values, and not against Content-Location header with CID: values. Thus, even though the following two headers are identical in meaning, only the Content-ID value will be matched, and the Content-Location value will be ignored. Content-ID: <email@example.com> Content-Location: CID: firstname.lastname@example.org Note: Content-IDs MUST be globally unique [MIME1]. It is thus not permitted to make them unique only within a message or within a single multipart/related structure.
ALT="IETF logo"> --boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example--
Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example Content-Location: images/ietflogo2.gif ; Note - Relative Content-Location is resolved by base ; specified in the Multipart/Related Content-Location heading Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo3.gif Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example--
--boundary-example Content-Location: ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example--
--boundary-example-1 Content-Location: http://www.ietf.cnri.reston.va.us/more-info Content-Type: multipart/related; boundary="boundary-example-2"; type="text/html" --boundary-example-2 Content-Type: text/html;charset="US-ASCII" Content-ID: <foo4@email@example.com> The image reference below will be resolved with the image in the surrounding multipart/related above. <IMG SRC="images/ietflogo.gif" ALT="IETF logo with white background"> The image reference below will be resolved with the image inside the current nested multipart/related below. <IMG SRC=images/ietflogo2e.gif" ALT="IETF logo with transparent background"> --boundary-example-2 Content-Location: http:images/ietflogo2.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4 SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa etc... --boundary-example-2-- --boundary-example-1 Content-Location: http://www.ietf.cnri.reston.va.us/even-more-info Content-Type: multipart/related; boundary="boundary-example-3"; type="text/html" --boundary-example-3 Content-Type: text/html;charset="US-ASCII" Content-ID: <4@firstname.lastname@example.org> The image reference below will be resolved with the image inside the current nested multipart/related below. <IMG SRC=images/ietflogo2d.gif" ALT="IETF logo with shadows"> The image reference below cannot be resolved according to this standard since references between parallel multipart/ related structures are not supported. <IMG SRC=images/ietflogo2e.gif" ALT="IETF logo with transparent background">
--boundary-example-3 Content-Location: http:images/ietflogo2d.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nz c3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v etc... --boundary-example-3-- --boundary-example-1-- 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 "á" or "á") 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 [MIME2] chapter 4. Note that the "charset" parameter refers only to the MIME character encoding. For example, the string "á" 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 in MIME format. Receiving 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 [MIME2] requires that e-mailed documents of "Content-Type: Text/ MUST be in canonical form before a Content- Transfer-Encoding is applied, 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. 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 based message 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 character sets 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. 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 e-mail, the charset parameter SHOULD be included, rather than relying on the default.
reference contained in a body part of the same multipart/related structure. Failure to honor this directive will allow a multipart/related structure to be employed as a Trojan Horse. For example, to inject bogus resources (i.e. a misrepresentation of a competitor's Web site) into a recipient's generally accessible Web cache. RELURL], Content-Location headers in multipart Content-Headings can now be used as a base to resolve relative URIs in their component parts, but only if no base URI can be derived from the component part itself. Base URIs in Content- Location header fields in inner headings have precedence over base URIs in outer multipart headings. The Content-Base header, which was present in RFC 2110, has been removed. A conservative implementor may choose to accept this header in input for compatibility with implementations of RFC 2110, but MUST never send any Content-Base header, since this header is not any more a part of this standard. A section 4.4.1 has been added, specifying how to handle the case of sending a body part whose URI does not agree with the correct URI syntax. The handling of relative and absolute URIs for matching between body parts have been merged into a single description, by specifying that relative URIs, which cannot be resolved otherwise, should be handled as if they had been given the URL "thismessage:/".
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [CONDISP] Troost, R. and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content- Disposition Header", RFC 2183, August 1997. [HOSTS] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. [HTML-I18N] Yergeau, F., Nicol, G. Adams, G. and M. Duerst: "Internationalization of the Hypertext Markup Language", RFC 2070, January 1997. [HTML2] Berners-Lee, T. and D. Connolly: "Hypertext Markup Language - 2.0", RFC 1866, November 1995. [HTML3.2] Dave Raggett: HTML 3.2 Reference Specification, W3C Recommendation, January 1997, at URL http://www.w3.org/TR/REC-html32.html [HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [IETF-TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [INFO] J. Palme: Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML), Work in Progress. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [MIDCID] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2387, August 1998. [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996. [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996. [MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, January 1997. [MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [NEWS] Horton, M. and R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987. [PDF] Tim Bienz and Richar Cohn: "Portable Document Format Reference Manual", Addison-Wesley, Reading, MA, USA, 1993, ISBN 0-201-62628-4. [REL] Levinson, E., "The MIME Multipart/Related Content- Type", RFC 2389, August 1998. [RELURL] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995. [RFC822] Crocker, D., "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] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [URLBODY] Freed, N. and K. Moore, "Definition of the URL MIME External-Body Access-Type", RFC 2017, October 1996.
[VRML] Gavin Bell, Anthony Parisi, Mark Pesce: "Virtual Reality Modeling Language (VRML) Version 1.0 Language Specification." May 1995, http://www.vrml.org/Specifications/. [XML] Extensible Markup Language, published by the World Wide Web Consortium, URL http://www.w3.org/XML/