MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
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. [STANDARDS-TRACK]
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 18 must, 11 should, 2 may.
2.1 Conformance requirement terminology
- MUSTAn implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements.
- MUSTAn 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."
4.2 The Content-Location Header
- SHOULDHowever, URI-s in Content-Location headers (if absolute, or resolvable to absolute URIs) SHOULD still be globally unique.
4.3 URIs of MHTML aggregates
- SHOULDIf a Content-Location header field is used in the heading of a multipart/related, this Content-Location SHOULD apply to the whole aggregate, not to its root part.
4.4.1 Encoding of URIs containing inappropriate characters
- MUSTThis encoding MUST only be done in the header, not in the HTML text.
- MUSTReceiving clients MUST decode the [MIME3] encoding in the heading before comparing URIs in body text to URIs in Content-Location headers.
- SHOULDThe charset parameter value "US-ASCII" SHOULD be used if the URI contains no octets outside of the 7-bit range.
- SHOULDIf 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.
- MUSTIf this cannot be safely established, the value "UNKNOWN-8BIT" [RFC 1428] MUST be used.
- MUSTNote, 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.
4.4.2 Folding of long URIs
- MUSTEncoding as discussed in clause 4.4.1 MUST be done before such folding.
5 Base URIs for resolution of relative URIs
- MUST(e) When the methods above do not yield an absolute URI, a base URL of "thismessage:/" MUST be employed.
6 Sending documents without linked objects
- MAYIf a text/html resource (object) is sent without subsidiary resources, to which it refers, it MAY be sent by itself.
7 Use of the Content-Type "multipart/related"
- SHOULDIf a message contains one or more MIME body parts containing URIs and also contains as separate body parts, resources, to which these URIs (as defined, for example, in HTML 2.0 [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].
- SHOULDWhen 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.
- SHOULDWhen 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.
- MUSTIn 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.
- SHOULDWhen a sending MUA sends objects which were retrieved from the WWW, it SHOULD maintain their WWW URIs.
- SHOULDIt SHOULD not transform these URIs into some other URI form prior to transmitting them.
- MUSTWithin 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.
8.3 Use of the Content-ID header and CID URLs
- MUSTWhen URIs employing a CID (Content-ID) scheme as defined in [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.
- MUSTNote: Content-IDs MUST be globally unique [MIME1].
10 Character encoding issues and end-of-line issues
- MAYIn 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.
- MUSTReceiving user agents (together with any Web browser they may use to display the document) MUST be capable of handling any combinations of these mechanisms.
- MUST- 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.
- SHOULDIf 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.
- SHOULDBecause 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.
11.2 Security considerations related to caching
- SHALLWhen processing (rendering) a text/html body part in an MHTML multipart/related structure, all URIs in that text/html body part which reference subsidiary resources within the same multipart/related structure SHALL be satisfied by those resources and not by resources from any another local or remote source.
- MUST NOTTherefore, if a sender wishes a recipient to always retrieve an URI referenced resource from its source, an URI labeled copy of that resource MUST NOT be included in the same multipart/related structure.
- MUST NOTIn addition, since the source of a resource received in a multipart/related structure can be misrepresented (see 11.1 above), if a resource received in multipart/related structure is stored in a cache, it MUST NOT be retrieved from that cache other than by a
12 Differences as compared to the previous version of this proposed
- MUSTA 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.