Sending html in e-mail

Jacob Palme <> Thu, 12 December 1996 15:19 UTC

Received: from by id aa02389; 12 Dec 96 10:19 EST
Received: from by id aa02216; 12 Dec 96 10:11 EST
Received: from localhost (jpalme@localhost) by (8.7.1/8.7.1) with SMTP id QAA07099; Thu, 12 Dec 1996 16:09:34 +0100 (MET)
Date: Thu, 12 Dec 1996 16:09:33 +0100 (MET)
From: Jacob Palme <>
To: IETF working group on HTML in e-mail <>
Subject: Sending html in e-mail
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.

The IETF working group on sending html in e-mail (mhtml) is now
ready with its proposed standard, we are only waiting for
approval by the IESG.

Short summary of the new standard:

The proposed standard will consist of three parts:

MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)
by Jacob Palme and Alexander Hopmann.

The MIME Multipart/Related Content-type by Ed Levinson.

Content-ID and Message-ID Uniform Resource Locators by Ed

All the documents are available for download from URL:
The version in the IETF drafts directory of the first of the
three documents is presently not quite up-to-date.

The main idea of our proposed standard is that you send a HTML
document, together with in-line graphics, applets, etc., and
also other linked documents if you so wish, in a MIME
multipart/related body part. Links in the HTML to other included
parts can be provided by CID (Content-ID) URLs or by any other
kind of URI, and the linked body part is identified in its
heading by either a Content-ID (linked to by CID URLs) or a
Content-Location (linked to by any other kind of URL. (In fact,
the "Content-ID: foo@bar header" can be seen as a special case
of the "Content-Location: CID: foo@bar header".)

The Content-Location identifies a URI for a content part, the
part need not be universally retrievable using this base.

The Content-Base identifies a base URI for a content, or for all
objects within it which do not have their own Content-Base.

URIs in HTML-formatted messages and in Content-Location headers
can be absolute and relative. If they are relative, and a
Content-Base exists, they are to be converted to absolute URIs
before matching with other body parts. If there is no
Content-Base header, and no Content-Location containing absolute
URIs, then exact matching of the relative URIs in the HTML and
the Content-Location of the linked parts is performed instead.

Future discussions on this should take place in the mhtml
mailing list. I am cross-posting this message to the ietf list.

Jacob Palme <> (Stockholm University and KTH)
for more info see URL: