Network Working Group                                       Jacob Palme
Internet Draft                                 Stockholm University/KTH
draft-ietf-mhtml-spec-02.txt                          Alexander Hopmann
Category-to-be: Proposed standard                ResNova Software, Inc.

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

Status of this Document

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).


Although HTML [RFC 1866] was designed within the context of MIME, more
than the specification of HTML as defined in RFC 1866 is needed for two
electronic mail user agents to be able to interoperate using HTML as a
document format. These issues include the naming of objects that are
normally referred to by URIs, and the means of aggregating objects that
go together. This document describes a set of guidelines that will allow
conforming mail user agents to be able to send, deliver and display
these objects, such as HTML objects. In addition it is hoped objects, that these techniques will
also apply to the wider category of URI-enabled objects. can contain links represdented
by URIs. In order to do
this, be able to handle inter-linked objects, the
document proposes to use the MIME type multipart/related and specifies
the MIME content-headers "Content-Location" and "Content-Base".

Table of Contents

1. Introduction
2. Terminology
   2.1 Conformance requirement terminology
   2.2 Other terminology
4. The Content-Location and Content-Base MIME Content Headers
   4.1 MIME content headers
   4.2 The Content-Base header
   4.3 The Content-Location Header
   4.4 Encoding of URIs in e-mail headers
5. Base URIs for resolution of relative URIs
6. Sending HTML documents without linked objects
7. Use of the Content-Type: Multipart/related
8. Format of Links to Other Body Parts
   8.1 General principle
   8.2 Use of the Content-Location header
   8.3 Use of the Content-ID header and CID URLs
9 Examples
   9.1 Example of a HTML body without included linked objects
   9.3 Example with relative URIs to an embedded GIF picture
   9.4 Example using CID URL and Content-ID header to an embedded GIF
10. Content-Disposition header
11. Encoding Considerations for HTML bodies Character encoding issues
   11.1 Character set issues
   11.2 Line break characters
12. Security Considerations
13. Acknowledgments
14. References
15. Author's Address

Mailing List Information

Further discussion on this document should be done through the mailing

To subscribe to this list, send a message to
which contains the text
SUB MHTML <your name (not your e-mail address)>

Archives of this list are available by anonymous ftp from
The archives are also available by e-mail. Send a message to
LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get a list of
the archive files, and then a new message "GET <file name>" to retrieve
the archive files.

Comments on less important details may also be sent to the editor, Jacob
Palme <>.

More information may also be available at URL:

1. Introduction

The HTML format is

There are a very common format for documents in the Internet, number of document formats, HTML [HTML2], PDF [PDF] and there VRML
for example, which provide links using URIs for their resolution. There
is an obvious need to be able to send documents in this format these formats in e-mail e-
mail [RFC821=SMTP, RFC822]. The "text/html" media type is defined
in RFC 1866 [HTML2]. This document gives additional
specifications on how to use the text/html media type as a Content-Type send such documents in MIME [RFC 1521=MIME1] e-mail e-
mail messages. HTML documents commonly include This version of this standard was based on full
consideration only of the needs for objects with links in the Text/HTML
media type (as defined in RFC 1866 [HTML2]), but the standard may still
be applicable also to other formats for sets of interlinked objects,
linked by URIs. There is no conformance requirement that implementations
claiming conformance to this standard are able to handle URI-s in other
document formats than HTML.

URIs in documents in HTML and other similar formats reference other
objects and resources, either embedded or directly accessible through
hypertext links. When mailing such a HTML document, it is often desirable to
also mail all of the additional resources that are referenced in it;
those elements are necessary for the complete interpretation of the HTML.
primary object.

An alternative way for sending an HTML documents document or other object
containing URIs in e-mail is to only send the URL, and let the recipient
look up the document using HTTP. That method is described in [URLBODY]
and is not described in this document.

2. Terminology

2.1 Conformance requirement terminology

This specification uses the same words as RFC 1123 [HOSTS] for defining
the significance of each particular requirement. These words are:

MUST    This word or the adjective "required" means that the item is
        an absolute requirement of the specification.

SHOULD  This word or the adjective "recommended" means that there may
        exist valid reasons in particular circumstances to ignore this
        item, but the full implications should be understood and the
        case carefully weighed before choosing a different course.

MAY     This word or the adjective "optional" means that this item is
        truly optional. One vendor may choose to include the item
        because a particular marketplace requires it or because it
        enhances the product, for example; another vendor may omit the
        same item.

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 RFC 1808 [RELURL].

CID                   See [MIDCID].

Content-Base          See section 4.2 below.

Content-ID            See [MIDCID].

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

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

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 RFC 1866 [HTML2].

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

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 illegally modified.

MIME                  See RFC 1521 [MIME1], [MIME2].

MUA                   Messaging User Agent.

PDF                   Portable Document Format, see [PDF].

Relative URI,         See RFC 1866 [HTML2] and RFC 1808[RELURL].

URI, absolute and     See RFC 1866 [HTML2].

URL                   See RFC 1738 [URL].

URL, relative         See [RELURL].

VRML                  Virtual Reality Markup Language.

3. Overview

An aggregate HTML object document is a MIME-encoded message that contains a root
document as well as other data that is required in order to represent
that document (inline pictures, style sheets, applets, etc.). Aggregate
HTML objects
documents can also include additional elements that are linked to the

first object.  It is important to keep in mind the differing needs of
several audiences. Mail sending agents might send aggregate HTML objects documents as
an encoding of normal day-to-day electronic mail. Mail sending agents
might also send aggregate HTML objects documents when a user wishes to mail a
particular document from the web to someone else. Finally mail sending
agents might send aggregate HTML documents as automatic responders, providing
access to WWW resources for non-IP connected clients.

Mail receiving agents also have several differing needs. Some mail
receiving agents might be able to receive an aggregate HTML document and
display it just as any other text content type would be displayed.
Others might have to pass this aggregate HTML document to an HTML a browsing program,
and provisions need to be made to make this possible.

Finally several other constraints on the problem arise. It is important
that it be possible for an HTML a document to be signed and for it to be able to
be transmitted to a client and displayed with a minimum risk of breaking
the message integrity (MIC) check that is part of the signature.

4. The Content-Location and Content-Base MIME Content Headers

4.1 MIME content headers

In order to resolve URI references to other body parts, two MIME content
headers are defined, Content-Location and Content-Base. Both these
headers can occur in any message or content heading, and will then be
valid within this heading and for its content.

In practice, at present only those URIs which are URLs are used, but it
is anticipated that other forms of URIs will in the future be used.

The syntax for these headers is, using the syntax definition tools from

    content-location ::= "Content-Location:" ( absoluteURI | relativeURI

    content-base ::= "Content-Base:" absoluteURI

where URI is at present (June 1996) restricted to the syntax for URLs as
defined in RFC 1738 [URL].

These two headers are valid only for exactly the content heading or
message heading where they occurs and its text. They are thus not valid
for the parts inside multipart headings, and are thus meaningless in
multipart headings.

These two headers may occur both inside and outside of a
multipart/related part.

4.2 The Content-Base header

The Content-Base gives a base for relative URIs occurring in other
heading fields and in content which do not have any BASE element in its
HTML code. Its value MUST be an absolute URI.

Example showing which Content-Base is valid where:

   Content-Type: Multipart/related; boundary="boundary-example-1";
                 type=Text/HTML; start=foo2*
    ; A Content-Base header cannot be placed here, since this is a
    ; multipart MIME object.


   Part 1:
   Content-Type: Text/HTML; charset=US-ASCII
   Content-ID: foo2*
   Content-Location: "http/"
   ;  This Content-Location must contain an absolute URI, since no base
   ;  is valid here.


   Part 2:
   Content-Type: Text/HTML; charset=US-ASCII
   Content-ID: foo4*
   Content-Location: "foo1.bar1" ; The Content-Base below applies to
                                 ; this relative URI
   Content-Base: "http:/"


4.3 The Content-Location Header

The Content-Location header specifies the URI that corresponds to the
content of the body part in whose heading the header is placed. Its
value CAN be an absolute or relative URI. Any URI or URL scheme may be
used, but use of non-standardized URI or URL schemes might entail some
risk that recipients cannot handle them correctly.

The Content-Location header can be used to indicate that the data sent
under this heading is also retrievable, in identical format, through
normal use of this URI. If used for this purpose, it must contain an
absolute URI or be resolvable, through a Content-Base header, into an
absolute URI. In this case, the information sent in the message can be
seen as a cached version of the original data.

The header can also be used for data which is not available to some or
all recipients of the message, for example if the header refers to an
object which is only retrievable using this URI in a restricted domain,
such as within a company-internal web space. The header can even contain
a fictious URI and need in that case not be globally unique.


Content-Type: Multipart/related; boundary="boundary-example-1";


   Part 1:
   Content-Type: Text/HTML; charset=US-ASCII

   ... ... <IMG SRC="fiction1/fiction2"> ... ...


   Part 2:
   Content-Type: Text/HTML; charset=US-ASCII
   Content-Location: "fiction1/fiction2"


4.4 Encoding of URIs in e-mail headers

Since MIME header fields have a limited length and URIs can get quite
long, these lines may have to be folded. If such folding is done, the
algorithm defined in [URLBODY] section 3.1 should be employed.

5. Base URIs for resolution of relative URIs

Relative URIs inside contents of MIME body parts are resolved relative
to a base URI. In order to determine this base URI, the first-listed
method in the following list applies.

  (a) There is a base specification inside the MIME body part
       containing the link which resolves relative URIs into absolute
       URIs. For example, HTML provides the BASE element for this.

  (b) There is a Content-Base header (as defined in section 4.2),
       specifying the base to be used.

  (c) There is a Content-Location header in the heading of the body
       part which can then serve as the base in the same way as the
       request URI can serve as a base for relative URIs within a file
       retrieved via HTTP [HTTP].

6. Sending HTML documents without linked objects

If a document, such as an HTML document object, is sent without other objects, to
which it is linked, it MAY be sent as a Text/HTML body part by itself.
In this case,
Multipart/related multipart/related need not be used.

Such a document may either not include any links, or contain links which
the recipient resolves via ordinary net look up, or contain links which
the recipient cannot resolve.

Inclusion of links which the recipient has to look up through the net
may not work for some recipients, since all e-mail recipients do not
have full internet connectivity. Also, such links may work for the
sender but not for the recipient, for example when the link refers to an
URI within a company-internal network not accessible from outside the

Note that documents with links that the recipient cannot resolve MAY be
sent, although this is discouraged. For example, two persons developing
a new HTML page may exchange incomplete versions.

7. Use of the Content-Type: Multipart/related

The use of URI references creates some additional issues for aggregate
HTML objects. Normal URI references can of course be used, however it is
likely that many user agents may not be able to retrieve those objects
referred to. This document provides a means for these additional objects
to be transmitted with the HTML and for the links between these objects
to be properly resolved.

If a message contains one or more Text/HTML MIME body parts containing links and
also contains as separate body parts, data, to which hyperlinks these links (as defined
defined, for example, in RFC 1866 [HTML2]) in the Text/HTML body parts refers, then this whole set
objects body parts (referring body parts and referred-to body parts) SHOULD
be sent within a Multipart/Related multipart/related body part as defined in [REL].

The root body part of the Multipart/related multipart/related SHOULD be of the Content-Type:
Text/HTML. Use of start object
for rendering the Content-Type: Multipart/Alternative, one of whose
parts is object, such as a text/html object, and which contains
links to objects in other body parts, or a multipart/alternative of Content-Type: Text/HTML, is also allowed, but implementors
which at least one alternative resolves to such a start object.
Implementors are warned warned, however, that many mail programs treat Multipart/Alternative
multipart/alternative as if it had been Multipart/Mixed multipart/mixed (even though
MIME [MIME1] requires support for
Multipart/Alternative). multipart/alternative).

[REL] requires that the type attribute of the "Content-Type:
multipart/related" statement be the type of the root object, and this
value can thus be "multipart/alternative". If the root is not the first
body part within the Multipart/related, multipart/related, [REL] further requires that its
Content-ID MUST be given in a start parameter to the Content-Type:
Multipart/Related "Content-Type:
multipart/related" header.

When presenting the root body part to the user, the additional body
parts within the Multipart/related multipart/related can be used:

    (a) For those recipients who only have e-mail but not full Internet

(b) For those recipients who for other reasons, such as firewalls
        or the use of company-internal links, cannot retrieve the
        linked body parts through the net.

       Note that this means that you can, via e-mail, send HTML which
        includes URIs which the recipient cannot resolve via HTTPor
        other connectivity-requiring URIs.

    (c) For items which are not available on the web.

    (d) For any recipient to speed up access.

The type parameter of the Content-Type: Multipart/related multipart/related MUST be the
same as the Content-Type of its root.

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 email message, as
well as verify the documents against their WWW counterpoints.

The Text/HTML body MAY contain

This standard does not cover the case where a multipart/related contains
links to MIME body parts outside of the
Multipart/Related current multipart/related or in
other MIME messages, but such usage is discouraged. even if methods similar to those described in this
standard are used. Implementors who provide such links are warned that many receiving
mailers implementing this standard may not be able to resolve such

Within such a Multipart/related, multipart/related, ALL different parts MUST have different
Content-Location or Content-ID values.

8. Format of Links to Other Body Parts

8.1 General principle

A Text/HTML body part part, such as a text/HTML body part, may contain hyperlinks to
objects which are included as other body parts in the same message and
within the same multipart/related content. Often such linked objects are
meant to be displayed inline to the reader of the main document. HTML version 2.0
[RFC 1866=HTML2] has only one way of specifying hyperlinks to such
inline embedded content, document; for
example, objects referenced with the IMG tag. tag in HTML [RFC 1866=HTML2].
New tags with this property are
however proposed in the ongoing development of
HTML (example: applet, frame).

In order to send such messages, there is a need to indicate which other
body parts are referred to by the links in the body parts containing
such links. For example, a body part of Content-Type: Text/HTML often
has links to other objects, which might be included in other body parts.
This parts
in the same MIME message. The referencing of other body parts is done in
the following way: For each body part containing links and each distinct
URI in the
Text/HTML document, within it, which refers to data which is sent in the same MIME
message, there SHOULD be a separate body part within the current
multipart/related part of the message containing this data. Each such

body part SHOULD contain a Content-Location header (see section 8.2) or
a Content-ID header (see section 8.3).

An e-mail system which claims conformance to this standard MUST support
receipt of Multipart/related multipart/related (as defined in section 7) with links
between body parts using both the Content-Location (as defined in
section 8.2) and the Content-ID method (as defined in section 8.3).

8.2 Use of the Content-Location header

If there is a Content-Base header, then the recipient MUST employ
relative to absolute resolution as defined in RFC 1808 [RELURL] of
relative URIs in both the HTML markup and the Content-Location header
before matching a hyperlink in the HTML markup to a Content-Location
header. The same applies if the Content-Location contains an absolute URL,
URI, and the HTML markup contains a BASE element so that relative URL-s URIs
in the HTML markup can be resolved.

If there is NO Content-Base header, and the Content-Location header
contains a relative URL, URI, then NO relative to absolute resolution SHOULD
be performed (even if there is a BASE specification, such as the BASE
element in HTML, in the HTML markup), body part containing the URI), and exact textual
match of the relative URL-s URI-s in the Content-Location and the HTML markup
is performed instead (after removal of LWSP introduced as described in
section 4.4 above).

The URI in the Content-Location header need not refer to an object which
is actually available globally for retrieval using this URI (after
resolution of relative URIs). However, URI-s in Content-Location headers
(if absolute, or resolvable to absolute URIs) SHOULD still be globally

8.3 Use of the Content-ID header and CID URLs

When CID (Content-ID) URLs as defined in RFC 1738 [URL] and RFC 1873
[MIDCID] is used for links between body parts, the Content-Location
statement will normally be replaced by a Content-ID header. Thus, the
following two headers are identical in meaning:

Content-Location: CID:

Note: Content-IDs MUST be globally unique [MIME1]. It is thus not
permitted to make them unique only within this message or within this

9 Examples

9.1 Example of a HTML body without included linked objects

The first example is the simplest form of an HTML email message. This is
not an aggregate HTML object, but simply one by itself. a message with a single HTML
body part. This message contains a hyperlink but does not provide the
ability to resolve the hyperlink. To resolve the hyperlink the receiving
client would need either IP access to the Internet, or an electronic
mail web gateway.

   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: Text/HTML; charset=US-ASCII

   <h1>Hi there!</h1>
   An example of an HTML message.<p>
   Try clicking <a href="">here.</a><p>

9.2 Example with absolute URIs to an embedded GIF picture:

   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: Multipart/related; multipart/related; boundary="boundary-example-1";
                 type=Text/HTML; start=foo3*

--boundary-example 1
      Content-Type: Text/HTML;charset=US-ASCII
      Content-ID: foo3*

      ... text of the HTML document, which might contain a hyperlink
      to the other body part, for example through a statement such as:
      <IMG SRC=""
       ALT="IETF logo">

      Content-Type: IMAGE/GIF
      Content-Transfer-Encoding: BASE64



9.3 Example with relative URIs to an embedded GIF picture

   Subject: A simple example
   Mime-Version: 1.0
   Content-Base: ""
   Content-Type: Multipart/related; multipart/related; boundary="boundary-example-1";

      --boundary-example 1
      Content-Type: Text/HTML; charset=ISO-8859-1
      Content-Transfer-Encoding: QUOTED-PRINTABLE

      ... text of the HTML document, which might contain a hyperlink
      to the other body part, for example through a statement such as:
      <IMG SRC="/images/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; &168;

      Content-Location: "/images/ietflogo.gif"
      Content-Type: IMAGE/GIF
      Content-Transfer-Encoding: BASE64



9.4 Example using CID URL and Content-ID header to an embedded GIF

   Subject: A simple example
   Mime-Version: 1.0
   Content-Type: Multipart/related; multipart/related; boundary="boundary-example-1";

      --boundary-example 1
      Content-Type: Text/HTML; charset=US-ASCII

      ... text of the HTML document, which might contain a hyperlink
      to the other body part, for example through a statement such as:
      <IMG SRC="cid:foo4*" ALT="IETF logo">

      Content-ID: foo4*
      Content-Type: IMAGE/GIF
      Content-Transfer-Encoding: BASE64


10. Content-Disposition header

Note the specification in [REL] on the relations between Content-
Disposition and Multipart/Related. multipart/related.

11. Encoding Considerations for HTML bodies Character encoding issues

11.1 Character set issues

A mail user agent that is composing a message using HTML has a choice in
how to represent and subsequently encode characters for the transmission
of the mail message.

However, there are some differences as to the default character
encoding, specified by the MIME "charset" parameter. If this parameter
is omitted: When transferred through HTTP, the default is [HTTP]:
          content-type: Text/HTML; charset=ISO-8859-1
When transferred via e-mail, the default is [MIME1]:
          content-type: Text/HTML; charset=US-ASCII

To avoid confusion, the MIME Content-Type parameter for Text/HTML SHOULD
always include a charset value, and not rely on

For the MIME e-mail default
of US-ASCII if no charset value is specified.

When sending HTML via MIME e-mail, three layers of encoding are relevant
as shown in Figure 1:

Displayed text                       Displayed text
      |                                    ^
      V                                    |
+-------------+                      +----------------+
| HTML editor |                      | HTML viewer    |
|             |                      | or Web browser |
+-------------+                      +----------------+
      |                                    ^
      V                                    |
HTML markup                          HTML markup
      |                                    ^
      V                                    |
+------------------+                 +-------------------+
| MIME content-    |                 | MIME content-     |
| transfer-encoder |                 | transfer-encoder  |
+------------------+                 +-------------------+
      |                                    ^
      V              +-----------+         |
transfer-encoding--->| Transport |-->transfer encoding

                        Figure 1

Definitions (see Figure 1):

Displayed text   A visual representation of the intended text.

HTML markup      A sequence of characters formatted according to the
                 HTML specification [HTML2].

MIME encoding    A sequence of octets physically forwarded via e-mail,
                 may include MIME content-transfer-encoding as specified in [MIME1].

HTML editor      Software used to produce HTML markup.

MIME content-    Software used to encode  and decode non-US-ASCII
transfer-encoder characters according to the MIME standard.

HTML viewer      Software used to display an HTML documents to recipients.

Note: Real implementations need not split functions document into different
modules as described above. The figure above is a logical model in order
to explain how rewriting and transport is done.

If the displayed text contains non-US-ASCII characters, these characters
might have to be rewritten if the transport (as is common in e-mail) is
set to handle only 7-bit characters. MIME-
compatible octet stream, the following three mechanisms are relevant:

- HTML markup [HTML2] as an application of SGML [SGML] allows some characters at the displayed text level to be
represented using either entity references or
  denoted by character entities as well as by numeric character
references (as defined in [HTML2] section 3.2.1).  For example,
  (e.g. "latin small letter a "small
a, acute accent" with acute" may be represented by the entity reference
  or "&225;") in the numeric character reference "&#255;". Alternatively, HTML markup.

- HTML documents, in common with other documents of the same MIME content-
  text, can use various kinds of character might appear directly encodings which are indicated
  by the value of the "charset" parameter in the HTML document, but for
transmission through MIME 7-bit-systems, content-type
  For the exact meaning and use of the "charset" parameter, please see
  [MIME1 section 7.1.1]. Note that the "charset" parameter refers to the
  charset in the entire HTML document is
encoded using markup, not to the charset in the displayed text.
  Thus, if the HTML markup contains only US-ASCII characters, then the
  value of the charset parameter should be US-ASCII, even if the HTML
  markup contains entities which cause the displayed text to show

- Any documents including HTML documents that contain octet values
  the 7-bit range or that contain bare CRs or bare LFs need a Content-Transfer-Encoding (as content-
  transfer-encoding applied before transmission over certain transport
  protocols [MIME1, chapter 5].

The above three mechanisms are well defined in [MIME1] section
5). and documented, and
therefore not further explained here. In sending a message containing non US-ASCII characters, both these
rewriting methods message, all the
abovementioned mechanisms MAY be used, and any mixture of them MAY occur
when sending the document via e-mail. Receiving mailers (together with
the Web browser they may use to display the document) MUST be capable of
handling any combinations of these rewriting methods.

The value of the charset attribute of the Content-Type header field
should be US-ASCII if and only mechanisms.

Some transport mechanisms may specify a default "charset" parameter if
none is suppled [HTTP, MIME1]. Because the default differs for different
mechanisms, when HTML markup contains only US-ASCII
characters (even if is transferred through mail, the displayed text contains non-US-ASCII
characters). charset parameter
SHOULD be included, rather than relying on the default.

Example of non-US-ASCII characters in HTML: See section 9.3 above.

11.2 Line break characters

The MIME standard [MIME1] specifies that line breaks in the MIME
encoding (see figure 1) content
MUST be CRLF. The HTTP standard [HTTP] specifies that line breaks in
transported HTML markup (see figure 2) may be either bare CRs, bare LFs or CRLFs. To
allow data integrity checks through checksums, MIME content-transfer-
encoding of line breaks SHOULD SHOULD, if necessary, be such used so that after
decoding, the line break representation of the original HTML markup is

Note that since the mail content-MD5 is defined to a canonical form with
all line breaks converted to CRLF, while the HTTP content-MD5 is defined
to apply to the transmitted form. This means that the Content-MD5 HTTP
header may not be correct for Text/HTML that is retrieved from a HTTP
server and then sent via mail.

12. Security Considerations

Some Security Considerations include the potential to mail someone an
object, and claim that it is represented by a particular URI (by giving
it a Content-Location: header). There can be no assurance that a WWW
request for that same URI would normally result in that same object. It
might be unsuitable to cache the data in such a way that the cached data
can be used for retrieval of this URI from other messages or message
parts than those included in the same message as the Content-Location
header. Because of this problem, receiving User Agents SHOULD not cache
this data in the same way that data that was retrieved through an HTTP
or FTP request might be cached.

URLs, especially File URLs, may in their name contain company-internal
information, which may then inadvertently be revealed to recipients of
documents containing such URLs.

One way of implementing messages with linked body parts is to handle the
linked body parts in a combined mail and WWW proxy server. The mail
client is only given the start body part, which it passes to a web
browser. This web browser requests the linked parts from the proxy
server. If this method is used, and if the combined server is used by
more than one user, then methods must be employed to ensure that body
parts of a message to one person is not retrievable by another person.
Use of passwords (also known as tickets or magic cookies) is one way of
achieving this. Note that some caching HTML WWW proxy servers may not
distinguish between cached objects from e-mail and HTTP, which may be a
security risk.

In addition, by allowing people to mail aggregate HTML objects, we are
opening the door to other potential security problems that until now
were only problems for WWW users. For example, some HTML documents now
either themselves contain executable content (JavaScript) or contain
links to executable content (The "INSERT" specification, Java). It would
be exceedingly dangerous for a receiving User Agent to execute content
received through a mail message without careful attention to
restrictions on the capabilities of that executable content.

13. Acknowledgments

Harald T. Alvestrand, Richard Baker, Dave Crocker, Martin J. Duerst,
Lewis Geer, Roy Fielding, Al Gilman, Paul Hoffman, Richard W. Jesmajian,
Mark K. Joseph, Greg Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed
Levinson, Jay Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin
Nicol, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski Zawinski, Steve
Zilles and several other people have helped us with preparing this
document. I alone take responsibility for any errors which may still be
in the document.

14. References

Ref.            Author, title
---------       --------------------------------------------------------

[CONDISP]       R. Troost, S. Dorner: "Communicating Presentation
                Information in Internet Messages: The Content-
                Disposition Header", RFC 1806, June 1995.

[HOSTS]         R. Braden (editor): "Requirements for Internet Hosts --
                Application and Support", STD-3, RFC 1123, October 1989.

[HTML2]         T. Berners-Lee, D. Connolly: "Hypertext Markup Language
                - 2.0", RFC 1866, November 1995.

[HTTP]          T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext
                Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.

[MIDCID]        E. Levinson: "Message/External-Body Content-ID Access
                Type", RFC 1873, December 1995.

[MIME1]         N. Borenstein & N. Freed: "MIME (Multipurpose Internet
                Mail Extensions) Part One: Mechanisms for Specifying and
                Describing the Format of Internet Message Bodies", RFC
                1521, Sept 1993.

[MIME2]         N. Borenstein & N. Freed: "Multipurpose Internet Mail
                Extensions (MIME) Part Two: Media Types". draft-ietf-
                822ext-mime-imt-02.txt, December 1995.

[NEWS]          M.R. Horton, R. Adams: "Standard for interchange of
                USENET messages", RFC 1036, December 1987.

[PDF]           Bienz, T., Cohn, R. and Meehan, J.: "Portable Document
                Format Reference Manual, Version 1.1", Adboe Systems
[REL]           Harald Tveit Alvestrand, Edward Levinson: "The MIME
                Multipart/Related Content-type", <draft-levinson-
                multipart-related-00.txt>, January 1995.

[RELURL]        R. Fielding: "Relative Uniform Resource Locators", RFC
                1808, June 1995.

[RFC822]        D. Crocker: "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:>

[SMTP]          J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
                821, August 1982.

[URL]           T. Berners-Lee, L. Masinter, M. McCahill: "Uniform
                Resource Locators (URL)", RFC 1738, December 1994.

[URLBODY]       N. Freed and Keith Moore: "Definition of the URL MIME
                External-Body Access-Type", draft-ietf-mailext-acc-url-
                01.txt, November 1995.

15. Author's Address

For contacting the editors, preferably write to Jacob Palme rather than
Alex Hopmann.

Jacob Palme                          Phone: +46-8-16 16 67
Stockholm University and KTH         Fax: +46-8-783 08 29
Electrum 230                         E-mail:
S-164 40 Kista, Sweden

Alex Hopmann
ResNova Software, Inc.               E-mail:
5011 Argosy Dr. #13 13
Huntington Beach, CA 92649

Working group chairman: Einar Stefferud <>