RFC 2557

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

📅 published March 1999, from ietf

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

Okay bestie, so this is RFC 2557 🎀, and it came out of the Network Working Group in March 1999. It's a Standards Track document, and it obsoletes RFC 2110 🦋. The authors are J. Palme (Stockholm University/KTH), A. Hopmann (Microsoft Corporation), and N. Shelness (Lotus Development Corporation) 👑. Main character energy, honestly ✨.

Status of this Memo

This document is an Internet standards track protocol spec for the Internet community 🌸. It asks for discussion and suggestions for improvements. To see where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅.

Copyright Notice

Abstract

Okay so, [RFC 1866] describes HTML as a seriously powerful way to specify multimedia documents 🔥. These documents are made of a text/html root resource (object) plus other subsidiary resources, like images, video clips, applets, and so on. Each of those is referenced by a Uniform Resource Identifier (URI) inside the root. When a browser pulls up one of these documents, every component gets fetched individually, in real time, from whatever location and protocol its own URI points to 🦋.

So if you want to send a full HTML multimedia document in a single e-mail message, you need two things. First, a) you have to bundle the text/html root and every subsidiary resource it references into one composite message structure. Second, b) you need a way for the URIs in that root to point at the subsidiary resources sitting inside that composite message 🎀.

This document is where both of those get sorted out ✨. It a) defines the use of a MIME multipart/related structure to bundle a text/html root resource together with the subsidiary resources it references. It also b) specifies a MIME content-header, Content-Location, which lets URIs in a text/html root body part reference subsidiary resources in other body parts of that same multipart/related structure 💜.

It was built for e-mail transfer of complete multi-resource HTML multimedia documents first. But these same conventions can also be used for resources retrieved by other transfer protocols such as HTTP and FTP. That means you can grab a whole multi-resource HTML document in one transfer, or store and archive complete HTML documents 🌈.

Differences between this and the 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

1. Introduction 🌸

There are a bunch of document formats that work this way: the Hypertext Markup Language [HTML2], the Extended Markup Language [XML], the Portable Document Format [PDF], and the Virtual Reality Markup Language [VRML] 🧚. Each one describes a document made of a root resource plus a number of separate subsidiary resources, and URIs inside that root point at them. So there's an obvious need to be able to send these multi-resource documents through e-mail [SMTP], [RFC822] messages 💌.

This standard is how you aggregate those multi-resource documents into MIME-formatted [MIME1 to MIME5] messages, and that's exactly what it's for 🎀.

This spec was developed to meet the specific aggregation needs of multi-resource HTML documents. But it may also be applicable to other multi-resource document representations that are linked by URIs 🦋. Even so, there's 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. So no pressure, just HTML 💅.

The 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. It could also help with archiving complete web pages as they appeared at a particular point in time 📸.

There's an informational RFC that'll be published as a supplement to this standard 📚. It talks about 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 at http://www.dsv.su.se/~jpalme/ietf/mhtml.html 🔗.

Here's the big idea: body parts you want to reference can be identified either by a Content-ID (which contains a Message-ID value) or by a Content-Location (which contains an arbitrary URL) 💖. Why not just recommend Content-IDs? Because it should be possible to forward existing web pages via e-mail without having to rewrite their source text. Rewriting has several disadvantages, and one of them is that security checksums will probably be invalidated 🙈.

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 📖. Here's the rundown:

   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.

   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].

   VRML                  See Virtual Reality Markup Language [VRML].

3. Overview ✨

okay so an aggregate document is a MIME-encoded message with a root resource (the object) plus other resources linked to it through URIs 🎀 Those other resources might be needed to display the multimedia document based on the root (inline pictures, style sheets, applets, etc.), or they might be the root resources of other multimedia documents. Keep in mind that aggregate documents have to satisfy the different needs of several audiences 💅

Mail sending agents might send aggregate documents as a normal day-to-day electronic mail encoding 📧 They might also send one when a user wants to mail a particular document from the web to someone else 💌 And mail sending agents might send them as automatic responders, giving access to WWW resources for non-IP connected clients 🤖 Other protocols like HTTP or FTP can also need to retrieve aggregate documents 🦋 Receiving agents have their own mix of needs too. Some can take an aggregate document and display it just like any other text content type 🌸 Others have to hand the aggregate document off to a browsing program, so there have to be provisions that make that possible 🧚

And then there are a few more constraints 😭 It's important that a document can be signed and still be transmitted and displayed without breaking the message integrity (MIC) checksum that's part of the signature 🔐

4. The Content-Location MIME Content Header 🌈

4.1 MIME content headers

okay so, to resolve URI references to resources in other body parts, one MIME content header gets defined: Content-Location 💖 This header can show up in any message or content heading ✨

The syntax for this header, written with the syntax definition tools from [ABNF], looks like this:

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 the IETF specifies other kinds of URIs 🦋

4.2 The Content-Location Header

A Content-Location header specifies a URI that labels the content of the body part in whose heading it's placed 🎀 Its value can be an absolute or a relative URI 💅 Any URI or URL scheme may be used, but using non-standardized URI or URL schemes might carry some risk that recipients can't handle them correctly ⚠️

A URI in a Content-Location header doesn't need to point to a resource that's globally available for retrieval using this URI (after resolution of relative URIs) 🌍 Still, URI-s in Content-Location headers (if they're absolute, or resolvable to absolute URIs) SHOULD still be globally unique ✨

So a Content-Location header can be used to label a resource that not all recipients (or any of them) can retrieve 🙈 For example, a Content-Location header might label an object that's only retrievable using this URI inside a restricted domain, like a company-internal web space 🏢 A Content-Location header can even contain a fictitious URI, and that kind of URI doesn't need to be globally unique 🧚

A single Content-Location header field is allowed in any message or content heading, next to a Content-ID header (as specified in [MIME1]) and, in message headings, a Message-ID (as specified in [RFC822]) 💜 All of these are different, equally valid body part labels, and any of them can be used to satisfy a reference to a body part 🫶 Multiple Content-Location header fields in the same message heading are not allowed 🚫

Here's an example of a multipart/related structure with body parts that have 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:97116092811xyz@foo.bar.net"> ... ...

   --boundary-example
   Content-Type: image/gif
   Content-ID: <97116092511xyz@foo.bar.net>
   Content-Location: fiction1/fiction2

   --boundary-example
   Content-Type: image/gif
   Content-ID: <97116092811xyz@foo.bar.net>
   Content-Location: fiction1/fiction3

   --boundary-example--

4.3 URIs of MHTML aggregates

The URI of an MHTML aggregate is NOT the same as the URI of its root 🙅 The root's URI only retrieves the root resource itself, even if a web browser may then separately retrieve in-line linked resources 🌸 If 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 🎀

When a URI referring to an MHTML aggregate gets used to retrieve that aggregate, the set of resources retrieved can be different from the set you'd get using the Content-Locations of its parts 👀 For example, retrieving an MHTML aggregate might give you an old version, while retrieving the root URI and its in-line linked objects might give you a newer version 🕰️

4.4 Encoding and decoding of URIs in MIME header fields

4.4.1 Encoding of URIs containing inappropriate characters

Some documents may contain URIs with characters that aren't appropriate for an RFC 822 header 😬 That happens either because the URI itself has an incorrect syntax according to [URL], or because the URI syntax standard has changed to allow characters that weren't allowed in MIME headers before 🔄 These URIs can't be sent directly in a message header. If one shows up, 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 that can't be safely established, the value "UNKNOWN-8BIT" [RFC 1428] MUST be used 🧾

Note that for matching URIs in text/html body parts to URIs in Content-Location headers, the value of the charset parameter is irrelevant. It may still matter for other purposes, though, so incorrect labeling MUST therefore be avoided 🏷️

Warning: the irrelevance of the charset parameter may not hold in the future, if different character encodings of the same non-English filename are used in HTML. 🚨

4.4.2 Folding of long URIs

Since MIME header fields have a limited length, and long URIs can result in Content-Location headers that exceed that length, Content-Location headers may have to be folded 📏

Encoding as discussed in clause 4.4.1 MUST be done before such folding. After that, the folding can be done using the algorithm defined in [URLBODY] section 3.1 🧩

4.4.3 Unfolding and decoding of received URLs in MIME header fields

When a message is received, folded MIME header fields should be unfolded, and then any MIME encoding should be removed, so you get the original URI back 🔓✨

5. Base URIs for resolution of relative URIs 🗺️

Relative URIs inside the contents of MIME body parts are resolved relative to a base URI, using the methods for resolving relative URIs described in [RELURL]. To figure out this base URI, the first-applicable method in the following list applies 📋

(a) There's a base specification inside the MIME body part containing the relative URI, and it resolves relative URIs into absolute URIs. For example, HTML provides the BASE element for this purpose 🎀
(b) There's 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 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 an HTTP response, use the URI that was used to initiate the request 🌸
(e) When the methods above don't yield an absolute URI, a base URL of thismessage:/ MUST be employed. This base URL is 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 💜

6. Sending documents without linked objects 📭

If a text/html resource (object) gets sent without the subsidiary resources it refers to, it MAY be sent by itself 🦋 In this case, embedding it in a multipart/related structure isn't necessary 🙌

A text/html resource like that may either contain no URIs, or contain URIs that the recipient is expected to retrieve (if possible) via a URI specified protocol 🌐 A text/html resource can also be sent with unresolvable links in special cases, like when two authors swap drafts of unfinished resources ✍️

Including URIs that point to resources the recipient has to retrieve via a URI specified protocol may not work for some recipients 😩 That's because not all e-mail recipients have full Internet connectivity, or because URIs that work for a sender won't work for a recipient 🙃 For example, this happens when a URI refers to a resource inside a company-internal network that isn't accessible from outside the company 🏢💀

okay bestie, so if a message has MIME body parts with URIs inside them (like the ones from HTML 2.0 [HTML2]) AND the resources those URIs point to are also in the message as their own separate body parts, then the whole squad, referring parts and referred-to parts together, SHOULD be sent inside a multipart/related structure as defined in [REL]. 🫶

Headers can totally show up in a message that has no multipart/related structure at all, but this standard only covers them for resolving URIs between body parts that live inside a multipart/related structure. 🎀 It does cover the case where a resource in a nested multipart/related structure has URIs pointing at MIME body parts in the multipart/related structure it's enclosed in. It does NOT cover a resource in one multipart/related structure pointing at body parts in another parallel or nested multipart/related structure, or in a different MIME message, even if you use similar methods. 🙈 If you're using URIs like that, receiving agents that follow this standard may not be able to process those references, so consider yourself warned! ⚠️

When the start body part of a multipart/related structure is an atomic object, like a text/html resource, it SHOULD be used as the root resource of that multipart/related structure. ✨ When the start body part is a multipart/alternative structure and it contains at least one alternative body part that's a suitable atomic object (like a text/html resource), then that body part SHOULD be used as the root resource of the aggregate document. 🌸 BUT, and this is a big but, some receiving agents treat multipart/alternative as if it were multipart/mixed, even though MIME [MIME1] requires support for multipart/alternative. Mess. 💀

[REL] says a type parameter is mandatory in a Content-Type: multipart/related header, and that it has to be used to specify the type of the multipart/related start object. So the type parameter value shall be multipart/alternative whenever the start part is Content-type multipart/alternative, even if the actual root resource is text/html. 💅 Also, if the multipart/related start object is NOT the first body part in the 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 you're rendering a resource in a multipart/related structure, the URI references inside that resource can be satisfied by body parts in that same multipart/related structure (see section 8.2 below). This is super useful for:

(a) Recipients who only have email and not full Internet access. 📧
(b) Recipients who, for other reasons (firewalls, company-internal links, etc.), can't retrieve URI-referenced resources through URI-specified protocols. 🧱

Note, that this means you can send text/html objects through email that include URIs the recipient can't resolve through HTTP or other connectivity-requiring URIs. 👀

(c) Sending a document whose content stays preserved even if the resources its embedded URIs refer to are later changed or deleted. 🦋
(d) Resources that aren't available for protocol-based retrieval. 🧚
(e) Speeding up access. 🚀

When a sending MUA sends objects that were retrieved from the WWW, it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs into some other URI form before transmitting them. 🙌 Why? Because this lets the receiving MUA verify MICs included with the message, and also verify the documents against their WWW counterparts, if that's appropriate. 🔍

Now, in certain cases this won't work. For example, if a resource contains URIs as parameters to objects and applets, it might be better to rewrite the document before sending it. This problem is discussed in more detail in the informational RFC that 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 Content-Location header field values that resolve to a different URI. 💜

Two body parts in the same multipart/related structure can have the same relative Content-Location header value, but only if they become different when resolved to absolute URIs. 🌈

8. Usage of Links to Other Body Parts 🔗

8.1 General principle

A body part, like a text/html body part, may contain URIs that reference resources included as body parts in the same message (more specifically, as body parts within the same multipart/related structure). Often these URI-linked resources are meant to be displayed inline to the viewer of the referencing body part, like objects referenced with the SRC attribute of the IMG element in HTML 2.0 [HTML2]. 🖼️ New elements and attributes with this property are being 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 that the reader can traverse, which are related through the href attribute of the A element. 🧭

If a user retrieves and displays a web page built from a text/html resource and its subsidiary resources, and then just saves the text/html resource, that user may not be able to retrieve and display the web page later the way it looked when they saved it. 😭 The format described in this standard can be used to archive and retrieve all the resources needed to display the web page as it originally appeared at one moment in time, all packed into one aggregate file. 📦

To send or store complete messages like this, we need a way to specify how a URI in one body part can reference a resource in another body part. 💖

8.2 Resolution of URIs in text/html body parts

Here's how inline, retrieval and other kinds of URIs in text/html body parts get resolved, step by step: 📝

(a) Unfold multiple line header values according to [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 the 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. That means if one of the two URIs being 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. 🤷‍♀️

8.3 Use of the Content-ID header and CID URLs

When URIs using 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, NOT against Content-Location header values with CID: in them. 🆔 So even though these two headers mean the same thing, only the Content-ID value will be matched, and the Content-Location value will be ignored:

   Content-ID: <foo@bar.net>
   Content-Location: CID: foo@bar.net

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. 🌍

9. Examples 🎀

Warning: The examples are provided for illustrative purposes only. If there is a contradiction between the explanatory text and the examples in this standard, then the explanatory text is normative. ⚠️

Notation: The examples contain indentation to show the structure. The real objects should not be indented in this way. 📐

9.1 Example of a HTML body without included linked objects

The first example is the simplest form of an HTML email message. 💌 It doesn't contain an aggregate HTML object, just a message with a single HTML body part. That body part contains a URI, but the message does NOT contain the resource that URI references. To retrieve that resource, the receiving client would need either IP access to the Internet or an electronic mail web gateway. 🌐

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: text/html; charset="iso-8859-1"
   Content-Transfer-Encoding: 8bit

   <HTML>
   <head></head>
   <body>
   <h1>Acute accent</h1>
   The following two lines look have the same screen rendering:<p>
   E with acute accent becomes �.<br>
   E with acute accent becomes &Eacute;.<p>
   Try clicking <a href="http://www.ietf.cnri.reston.va.us/">
   here.</a><p>
   </body></HTML>

9.2 Example with an absolute URI to an embedded GIF picture

The second example is an HTML message that includes a single image, referenced using the Content-Location mechanism. 🖼️✨

   From: foo1@bar.net
   To: foo2@bar.net
   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: multipart/related; boundary="boundary-example";
           type="text/html"; start="<foo3@foo1@bar.net>"

   --boundary-example
   Content-Type: text/html;charset="US-ASCII"
   Content-ID: <foo3@foo1@bar.net>

   ... text of the HTML document, which might contain a URI
   referencing a resource in another body part, for example
   through a statement such as:
   <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"

    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--

9.3 Example with relative URIs to embedded GIF pictures ✨

okay so this one is giving base URL drama 🎀 The Content-Location header in the outermost heading is the base for ALL the relative URLs, even the ones inside the HTML text being sent. no cap, that's the main character move 👑

From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Location: http://www.ietf.cnri.reston.va.us/
Content-Type: multipart/related; boundary="boundary-example";
        type="text/html"

--boundary-example
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: QUOTED-PRINTABLE

... text of the HTML document, which might contain URIs
referencing resources in other body parts, for example through
statements such as:

<IMG SRC="images/ietflogo1.gif" ALT="IETF logo1">
<IMG SRC="images/ietflogo2.gif" ALT="IETF logo2">
<IMG SRC="images/ietflogo3.gif" ALT="IETF logo3">

Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: &#168;

--boundary-example
Content-Location:
         http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif
; Note - Absolute Content-Location does not require a
; base
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--

9.4 Example with a relative URI and no BASE available 🧚

bestie, this one has NO base 😭 so the only thing we've got is the relative URI on its own. it's giving bare minimum, but it's still a valid vibe 💅

From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
        type="text/html"

--boundary-example
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: QUOTED-PRINTABLE

... text of the HTML document, which might contain a URI
referencing a resource in another body part, for example
through a statement such as:
<IMG SRC="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
Content-Location: ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

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

--boundary-example--

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

this is the CID era, and it's so iconic 🌈 The HTML points at the image with a cid: URL, and the image part matches it with a Content-ID header. the Content-Location in this part is just a vibe check, because it gets totally ignored 🙈

From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
        type="text/html"

--boundary-example
Content-Type: text/html; charset="US-ASCII"

... text of the HTML document, which might contain a URI
referencing a resource in another body part, for example
through a statement such as:
<IMG SRC="cid:foo4@foo1@bar.net" ALT="IETF logo">

--boundary-example
Content-Location: CID:something@else ; this header is disregarded
Content-ID: <foo4@foo1@bar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

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

--boundary-example--

9.6 Example showing permitted and forbidden references between nested body parts 🌸

okay this is the big one, and it's a whole drama 🍓 It shows which references are allowed between multipart/related body parts and which ones are NOT allowed, so pay attention bestie 👀

From: foo1@bar.net
To: foo2@bar.net
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"
Content-ID: <foo3@foo1@bar.net>

The image reference below will be resolved with the image
in the next body part.
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
ALT="IETF logo with white background">

The image reference below cannot be resolved within this
MIME message, since it contains a reference from an outside
body part to an inside body part, which is not supported
by this standard.
<IMG SRC=images/ietflogo2e.gif"
ALT="IETF logo with transparent background">

The anchor reference immediately below will be resolved with
the nested text/html body part below:
<A HREF="http://www.ietf.cnri.reston.va.us/more-info>
More info</A>

The anchor reference immediately below will be resolved with
the nested text/html body part below:
<A HREF="http://www.ietf.cnri.reston.va.us/even-more-info>
Even more info</A>

--boundary-example-1
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-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@foo1@bar.net>

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@foo@bar.net>

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--

10. Character encoding issues and end-of-line issues 💖

okay so this section is all about getting characters across the wire without them getting mangled 🫶 There are a few mechanisms that matter here, and they're all well documented, so the original doesn't explain them again. We're just going to hit the highlights.

HTML [HTML2], [HTML-I18N] as an application of SGML [SGML] lets you denote characters with character entities or numeric character references. Like, "Latin small letter a with acute accent" can be á or á in the HTML markup. ✨
HTML documents, like other documents with the MIME Content-Type "text", can be represented in MIME using one of several character encodings. The charset parameter value tells you which encoding was used. For the exact meaning and use of charset, check [MIME2] chapter 4. 🎀

Note that the charset parameter only refers to the MIME character encoding 👀 For example, the string á can be sent in MIME with charset=US-ASCII, but the raw "Latin small letter a with acute accent" character cannot, because it's not ASCII. no cap, that's a plot twist 🙈

In sending a message, all of the mechanisms above MAY be used, and any mixture of them MAY occur when the document is sent in MIME format. Receiving user agents (together with any Web browser they may use to display the document) MUST be capable of handling any combination 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 survive moving a document from the HTTP to the MIME environment. If a document has to be converted in a way that makes a checksum-based message integrity check 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 cannot 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 between mechanisms, when HTML is transferred through e-mail, the charset parameter SHOULD be included rather than relying on the default. That's the bestie move 💜

11. Security Considerations 🔥

okay bestie, this part is serious but also kind of iconic 😭 A sender can totally lie about where a multipart/related body part came from by giving it a Content-Location URI that points at some other resource 🙈 So recipients should only treat Content-Location URIs as labels for resolving references from body parts in that same multipart/related message 🧩. They should NOT treat them as the real source of a resource, unless something else can verify it 🕵️‍♀️

URIs can also spill secrets. Especially File URIs 📁 If they get used as-is in a message, they might reveal stuff that was never meant to leave a particular security context 👀 Senders building messages with the new header fields defined in this standard should take care not to reveal anything outside the security contexts those fields belong to 🫶

Some resource servers hide passwords and tickets (access tokens to info that shouldn't be shared with others) and other sensitive stuff in invisible fields or URIs inside a text/html resource 💀 If that text/html resource gets forwarded in an email, the sensitive info can be revealed to people it was never meant for. Not it 🙅‍♀️

HTML can contain executable content directly (like JavaScript), or reference it indirectly (the "INSERT" specification, and Java) ⚠️ So it is exceedingly dangerous for a receiving User Agent to run content from a mail message without carefully paying attention to the limits on what that executable content is allowed to do 🚨

HTML-formatted messages can also be used to snoop on people 😱 They can break anonymity and invade individuals' privacy. If you send a message with an inline link to an object that isn't actually included in the message, the recipient's mailer or browser may go and request that object over HTTP. That HTTP transaction then reveals who is reading the message 👁️ For example, someone who wants to find out who's behind an anonymous user identity, or which workstation a user reads their mail from, could send a message with an inline link and then just watch where that link gets requested from 🕰️

there's a well-known problem with caching directly retrieved web resources. A resource pulled from a cache may be different from the one you'd get if you re-retrieved it from its source 🌀 This problem also shows up when a copy of a resource gets delivered inside a multipart/related structure 🎁

When processing (rendering) a text/html body part in an MHTML multipart/related structure, every URI in that text/html body part that references subsidiary resources within the same multipart/related structure SHALL be satisfied by those resources, and NOT by resources from any other local or remote source 💖

So, if a sender wants a recipient to always fetch a URI-referenced resource from its source, then a URI-labeled copy of that resource MUST NOT be included in the same multipart/related structure 🙅‍♀️

And since the source of a resource received in a multipart/related structure can be misrepresented (see 11.1 above), a resource received that way that gets stored in a cache MUST NOT be retrieved from that cache except by a reference contained in a body part of the same multipart/related structure. Ignore this and the multipart/related structure can be used as a Trojan Horse 🐴⚔️ For example, someone could inject bogus resources (basically pretending to be a competitor's Web site) into a recipient's generally accessible Web cache. Yikes 💅

12. Differences as compared to the previous version of this proposed standard in RFC 2110 🆕

the spec has been updated to show that these formats don't only apply to multipart MIME in email, but also to multipart MIME transferred through other protocols like HTTP or FTP 🌐

To agree with [RELURL], Content-Location headers in multipart Content-Headings can now be used as a base for resolving 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 now take precedence over base URIs in outer multipart headings 👑

The Content-Base header, which was in RFC 2110, has been removed 🗑️ A conservative implementor may choose to accept this header on input for compatibility with RFC 2110 implementations, but MUST never send any Content-Base header, since it's no longer part of this standard 🫠

A section 4.4.1 has been added, specifying how to handle sending a body part whose URI doesn't follow the correct URI syntax 📝

Handling of relative and absolute URIs for matching between body parts has been merged into one single description. Relative URIs that can't be resolved otherwise should be handled as if they had been given the URL thismessage:/ ✨

13. Acknowledgments 🫶

Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W. Peck, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve Zilles and several other people helped us prepare this document 💜 The authors alone take responsibility for any errors that may still be in it 🌸

14. References 📚

[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/

15. Authors' Addresses 💌

For contacting the editors, preferably write to Jacob Palme.

Jacob Palme
Stockholm University and KTH
Electrum 230
S-164 40 Kista, Sweden

Phone: +46-8-16 16 67
Fax: +46-8-783 08 29
EMail: jpalme@dsv.su.se


Alex Hopmann
Microsoft Corporation
One Microsoft Way
Redmond WA 98052

Phone: +1-425-703-8238
EMail: alexhop@microsoft.com


Nick Shelness
Lotus Development Corporation
55 Cambridge Parkway
Cambridge MA  02142-1295

EMail: Shelness@lotus.com


Working group chairman:

Einar Stefferud
EMail: stef@nma.com

16. Full Copyright Statement ✨

Okay, this is the legal part, but make it cute 🎀

So basically, anyone can copy this document and send it to their friends, and translations too 💌. People can also make derivative works that comment on or explain it, or help people actually implement it, and those can be prepared, copied, published and distributed, in whole or in part, without restriction of any kind 💅. The one condition is that the copyright notice above and this paragraph have to be included on all of those copies and derivative works 🫶.

But the document itself can't be modified in any way 🙅‍♀️. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: you can do it when you need to for developing Internet standards, but then the copyright procedures in the Internet Standards process must be followed 📜, or when you're translating it into languages other than English 🌍.

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns 💜. Not going anywhere, bestie 🦋.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

📦 where this page comes from

ietf: rfc2557 1999-03
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms