draft-ietf-mhtml-rev-02.txt   draft-ietf-mhtml-rev-03.txt 
Network Working Group Jacob Palme Network Working Group Jacob Palme
Internet Draft Stockholm University/KTH Internet Draft Stockholm University/KTH
draft-ietf-mhtml-rev-02.txt Alexander Hopmann draft-ietf-mhtml-rev-03.txt Alexander Hopmann
IETF status to be: Proposed standard Microsoft Corporation IETF status to be: Proposed standard Microsoft Corporation
Revises: RFC 2110 Revises: RFC 2110
Expires: March 1998 October 1997 Expires: May 1998 November 1997
MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
Status of this Document Status of this Document
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
Although HTML [RFC 1866] was designed within the context of MIME, Although HTML [RFC 1866] was designed within the context of MIME,
more than the specification of HTML as defined in RFC 1866 is needed 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 for two electronic mail user agents to be able to interoperate using
HTML as a document format. These issues include the naming of HTML as a document format. These issues include the naming of
skipping to change at line 62 skipping to change at line 62
2.1 Conformance requirement terminology 2.1 Conformance requirement terminology
2.2 Other terminology 2.2 Other terminology
3. Overview 3. Overview
4. The Content-Location and Content-Base MIME Content Headers 4. The Content-Location and Content-Base MIME Content Headers
4.1 MIME content headers 4.1 MIME content headers
4.2 The Content-Location Header 4.2 The Content-Location Header
4.3 The Content-Base header 4.3 The Content-Base header
4.4 Encoding of URIs in MIME headers 4.4 Encoding of URIs in MIME headers
5. Base URIs for resolution of relative URIs 5. Base URIs for resolution of relative URIs
6. Sending documents without linked objects 6. Sending documents without linked objects
7. Use of the Content-Type: "multipart/related" 7. Use of the Content-Type "multipart/related"
8. Usage of Links to Other Body Parts 8. Usage of Links to Other Body Parts
8.1 General principle 8.1 General principle
8.2 Resolution of hyperlinks in text/html body parts 8.2 Resolution of hyperlinks in text/html body parts
8.3 Use of the Content-ID header and CID URLs 8.3 Use of the Content-ID header and CID URLs
8.4 Conformance requirement on receipt 8.4 Conformance requirement on receipt
9. Examples 9. Examples
9.1 Example of a HTML body without included linked objects 9.1 Example of a HTML body without included linked objects
9.2 Example with absolute URIs to an embedded GIF picture 9.2 Example with absolute URIs to an embedded GIF picture
9.3 Example with relative URIs to an embedded GIF picture 9.3 Example with relative URIs to an embedded GIF picture
9.4 Example with relative URIs and no BASE available 9.4 Example with relative URIs and no BASE available
skipping to change at line 163 skipping to change at line 163
URIs in documents in HTML and other similar formats reference other URIs in documents in HTML and other similar formats reference other
objects and resources, either embedded or directly accessible through objects and resources, either embedded or directly accessible through
hypertext links. When mailing such a document, it is often desirable to hypertext links. When mailing such a document, it is often desirable to
also mail all of the additional resources that are referenced in it; also mail all of the additional resources that are referenced in it;
those elements are necessary for the complete interpretation of the those elements are necessary for the complete interpretation of the
primary object. Also with other protocols such as HTTP or FTP, it can primary object. Also with other protocols such as HTTP or FTP, it can
sometimes be desirable to send several documents in one aggregate sometimes be desirable to send several documents in one aggregate
document. document.
Since the formats specified in this standard specifies a way of saving
a complete web page with all in-line objects copied into one single
file, the formats might also be useful for archiving of complete web
page as they looked at a particular moment of time.
An alternative way for sending an HTML document or other object An alternative way for sending an HTML document or other object
containing URIs in email is to only send the URI, and let the recipient containing URIs in email is to only send the URI, and let the recipient
look up the document using HTTP. That method is described in [URLBODY] look up the document using HTTP. That method is described in [URLBODY]
and is not described in this document. and is not described in this document.
An informational RFC will be published as a supplement to this An informational RFC will be published as a supplement to this
standard. The informational RFC will discuss implementation methods and standard. The informational RFC will discuss implementation methods and
some implementation problems. Implementors are recommended to read this some implementation problems. Implementors are recommended to read this
informational RFC when developing implementations of the MHTML informational RFC when developing implementations of the MHTML
standard. This informational RFC is, when this RFC is published, still standard. This informational RFC is, when this RFC is published, still
skipping to change at line 300 skipping to change at line 305
4.1 MIME content headers 4.1 MIME content headers
In order to resolve URI references to other body parts, two MIME In order to resolve URI references to other body parts, two MIME
content headers are defined, Content-Location and Content-Base. Both content headers are defined, Content-Location and Content-Base. Both
these headers can occur in any message or content heading, and will these headers can occur in any message or content heading, and will
then be valid within this heading and for its immediate content. then be valid within this heading and for its immediate content.
These two headers are valid for the content heading or message heading These two headers are valid for the content heading or message heading
where they occur and its text. If they occur in multipart headings, where they occur and its text. If they occur in multipart headings,
they apply to its body parts only in that they can be used to derive a they apply to its body parts only in that they can be used to derive a
base for relative URIs in the body parts, but only if no such base is base for relative URIs in the body parts, and only if no such base is
provided in the body part itself. provided in the body part itself or in headings closer to the body.
These two headers may occur on any message or content heading, but These two headers may occur on any message or content heading, but
their usage for handling hyperlinks between body parts in a message their usage for handling hyperlinks between body parts in a message
SHOULD only occur inside the same "multipart/related". SHOULD only occur inside the same "multipart/related".
In practice, at present only those URIs which are URLs are used, but it 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. 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 The syntax for these headers is, using the syntax definition tools from
[RFC822]: [RFC822]:
skipping to change at line 438 skipping to change at line 443
4.4.1 Handling of URIs containing inappropriate characters 4.4.1 Handling of URIs containing inappropriate characters
Some documents may contain URIs with characters that are inappropriate Some documents may contain URIs with characters that are inappropriate
for an RFC 822 header, either because the URI itself has an incorrect for an RFC 822 header, either because the URI itself has an incorrect
syntax according to [URL] or the URI syntax standard has been changed syntax according to [URL] or the URI syntax standard has been changed
to allow characters not previously allowed in MIME headers. These URIs to allow characters not previously allowed in MIME headers. These URIs
cannot be sent directly in a message header. There are two approaches cannot be sent directly in a message header. There are two approaches
that can be taken when encountering such a URI as the text to be placed that can be taken when encountering such a URI as the text to be placed
in a Content-Location or Content-Base header: in a Content-Location or Content-Base header:
a) In some situations, an implementation might be able to replace the (a) In some situations, an implementation might be able to replace the
URI with one that can be sent directly. This might be accomplished, for URI with one that can be sent directly. This might be accomplished,
example, by using the encoding method of [URL] to replace inappropriate for example, by using the encoding method of [URL] to replace
characters within the URI with ones encoded using the "%nn" encoding. inappropriate characters within the URI with ones encoded using the
This replacement MUST in that case be done both in the header and in "%nn" encoding. This replacement MUST in that case be done both in
the HTML text which has a hyperlink which is to match the header. Since the header and in the HTML text which has a hyperlink which is to
the change is done in both places, a receiving agent need not decode match the header. Since the change is done in both places, a
it, and MUST NOT decode [URL]-encoding before matching hyperlinks to receiving agent need not decode it, and MUST NOT decode [URL]-
body parts. encoding before matching hyperlinks to body parts.
b) The URI might be encoded using the method described in [MIME3]. This (b) The URI might be encoded using the method described in [MIME3].
replacement MUST only be done in the header, not in the HTML text. This replacement MUST only be done in the header, not in the HTML
Receiving clients must decode the [MIME3] encoding in the heading text. Receiving clients must decode the [MIME3] encoding in the
before comparing hyperlinks in body text to URIs in Content-Location heading before comparing hyperlinks in body text to URIs in
headers. Content-Location headers.
With method (b), the charset parameter value "US-ASCII" SHOULD be used With method (b), the charset parameter value "US-ASCII" SHOULD be used
if the URI contains no octets outside of the 7-bit range. If such 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. octets are present, the correct charset parameter value (derived e.g.
from information about the HTML document the URI was found in) SHOULD from information about the HTML document the URI was found in) SHOULD
be used. If this cannot be safely established, the value "UKNOWN-8BIT" be used. If this cannot be safely established, the value "UKNOWN-8BIT"
[RFC 1428] MUST be used. [RFC 1428] MUST be used.
Note that for the MHTML processing of matching URIs in body text to URI Note that for the MHTML processing of matching URIs in body text to URI
in Content-Location headers the value of the charset parameter is in Content-Location headers the value of the charset parameter is
skipping to change at line 543 skipping to change at line 548
may not work for some recipients, since all email recipients do not may not work for some recipients, since all email recipients do not
have full internet connectivity. Also, such links may work for the have full internet connectivity. Also, such links may work for the
sender but not for the recipient, for example when the link refers to sender but not for the recipient, for example when the link refers to
an URI within a company-internal network not accessible from outside an URI within a company-internal network not accessible from outside
the company. the company.
Note that documents with links that the recipient cannot resolve MAY be Note that documents with links that the recipient cannot resolve MAY be
sent, although this is discouraged. For example, two persons developing sent, although this is discouraged. For example, two persons developing
a new HTML page may exchange incomplete versions. a new HTML page may exchange incomplete versions.
7. Use of the Content-Type: "multipart/related" 7. Use of the Content-Type "multipart/related"
If a message contains one or more MIME body parts containing links and If a message contains one or more MIME body parts containing links and
also contains as separate body parts, data, to which these links (as also contains as separate body parts, data, to which these links (as
defined, for example, in HTML 2.0 [HTML2]) refers, then this whole set defined, for example, in HTML 2.0 [HTML2]) refers, then this whole set
of body parts (referring body parts and referred-to body parts) SHOULD of body parts (referring body parts and referred-to body parts) SHOULD
be sent within a "multipart/related" body part as defined in [REL]. be sent within a "multipart/related" body part as defined in [REL].
Even though Content-Location and Content-Base can occur without Even though Content-Location and Content-Base can occur without
multipart/related, this standard only covers their use for resolution multipart/related, this standard only covers their use for resolution
of links between body parts inside one multipart/related. This standard of links between body parts inside one multipart/related. This standard
skipping to change at line 567 skipping to change at line 572
The root body part of the "multipart/related" SHOULD be the start The root body part of the "multipart/related" SHOULD be the start
object for rendering the object, such as a text/html object, and which object for rendering the object, such as a text/html object, and which
contains links to objects in other body parts, or a contains links to objects in other body parts, or a
multipart/alternative of which at least one alternative resolves to multipart/alternative of which at least one alternative resolves to
such a start object. Implementors are warned, however, that some such a start object. Implementors are warned, however, that some
receiving agents treat multipart/alternative as if it had been receiving agents treat multipart/alternative as if it had been
multipart/mixed (even though MIME [MIME1] requires support for multipart/mixed (even though MIME [MIME1] requires support for
multipart/alternative). multipart/alternative).
[REL] specifies that the type attribute is mandatory in Content-Type: [REL] specifies that the type attribute is mandatory in "Content-Type:
"multipart/related" headers, and requires that this attribute be the multipart/related" headers, and requires that this attribute be the
type of the root object, and this value shall thus for example be type of the root object, and this value shall thus for example be
"multipart/alternative", if the root part is of Content-type "multipart/alternative", if the root part is of "Content-type
"multipart/alternative", even if one of the subparts of the multipart/alternative", even if one of the subparts of the
"multipart/alternative" is of type "text/html". If the root is not the "multipart/alternative" is of type "text/html". If the root is not the
first body part within the "multipart/related", [REL] further requires first body part within the "multipart/related", [REL] further requires
that its Content-ID MUST be given in a start parameter to the that its Content-ID MUST be given in a start parameter to the
"Content-Type: "multipart/related" header. "Content-Type: multipart/related" header.
When presenting the root body part to the user, the additional body When presenting the root body part to the user, the additional body
parts within the "multipart/related" can be used: parts within the "multipart/related" can be used:
(a) For those recipients who only have email but not full Internet (a) For those recipients who only have email but not full Internet
access. access.
(b) For those recipients who for other reasons, such as firewalls or (b) For those recipients who for other reasons, such as firewalls or
the use of company-internal links, cannot retrieve the linked body the use of company-internal links, cannot retrieve the linked body
parts through the net. parts through the net.
skipping to change at line 599 skipping to change at line 604
connectivity-requiring URIs. connectivity-requiring URIs.
(c) To send a document in a format which is preserved even if the (c) To send a document in a format which is preserved even if the
object to which the hyperlinks refer through HTTP is later changed object to which the hyperlinks refer through HTTP is later changed
or deleted. or deleted.
(d) For items which are not available on the web. (d) For items which are not available on the web.
(e) For any recipient to speed up access. (e) For any recipient to speed up access.
The type parameter of the "Content-Type: "multipart/related" MUST be The type parameter of the "Content-Type: multipart/related" MUST be the
the same as the Content-Type of its root. same as the Content-Type of its root.
When a sending MUA sends objects which were retrieved from the WWW, it 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 SHOULD maintain their WWW URIs. It SHOULD not transform these URIs into
some other URI form prior to transmitting them. This will allow the some other URI form prior to transmitting them. This will allow the
receiving MUA to both verify MICs included with the message, as well as receiving MUA to both verify MICs included with the message, as well as
verify the documents against their WWW counterpoints. verify the documents against their WWW counterpoints.
In certain special cases this will not work if the original HTML In certain special cases this will not work if the original HTML
document contains URIs as parameters to objects and applets. In such a document contains URIs as parameters to objects and applets. In such a
case, it might be better to rewrite the document before sending it. case, it might be better to rewrite the document before sending it.
skipping to change at line 635 skipping to change at line 640
Two body parts in the same multipart/related can have the same relative Two body parts in the same multipart/related can have the same relative
URI as value of their Content-Location headers only if there are URI as value of their Content-Location headers only if there are
headers containing a different Content-Base header, so that the headers containing a different Content-Base header, so that the
absolute URI after resolution against the Content-Base header is absolute URI after resolution against the Content-Base header is
different. different.
8. Usage of Links to Other Body Parts 8. Usage of Links to Other Body Parts
8.1 General principle 8.1 General principle
A body part, such as a text/html body part, may contain hyperlinks A body part, such as a text/html body part, may contain hyperlinks to
to objects which are included as other body parts in the same message objects which are included as other body parts in the same message and
and within the same "multipart/related" content. Often such linked within the same "multipart/related" content. Often such linked objects
objects are meant to be displayed inline to the reader of the main are meant to be displayed inline to the reader of the main document;
document; for example, objects referenced with the src attribute for example, objects referenced with the src attribute of the IMG
of the IMG element in HTML 2.0 [HTML2]. New elements and attributes element in HTML 2.0 [HTML2]. New elements and attributes with this
with this property are proposed in the ongoing development of HTML property are proposed in the ongoing development of HTML (examples:
(example: applet, frame, profile, OBJECT, classid, codebase, data, applet, frame, profile, OBJECT, classid, codebase, data, SCRIPT). A
SCRIPT). A sender might also want to send a set of HTML documents sender might also want to send a set of HTML documents which the reader
which the reader can traverse, and which are related with the can traverse, and which are related with the attribute href of the A
attribute href of the A element. element.
In order to send such messages, there is a need to indicate which other 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 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 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 has links to other objects, which might be included in other body parts
in the same MIME message. in the same MIME message.
8.2 Resolution of hyperlinks in text/html body parts 8.2 Resolution of hyperlinks in text/html body parts
The resolution of hyperlinks in text/html body parts is performed in The resolution of hyperlinks in text/html body parts is performed in
the following way: the following way:
(a) Unfold multiple line header values according to [URLBODY]. Do NOT (a) Unfold multiple line header values according to [URLBODY]. Do NOT
however translate character encodings of the kind described in however translate character encodings of the kind described in
skipping to change at line 747 skipping to change at line 752
An example of an HTML message.<p> An example of an HTML message.<p>
Try clicking <a href="http://www.resnova.com/">here.</a><p> Try clicking <a href="http://www.resnova.com/">here.</a><p>
</body></HTML> </body></HTML>
9.2 Example with absolute URIs to an embedded GIF picture 9.2 Example with absolute URIs to an embedded GIF picture
From: foo1@bar.net From: foo1@bar.net
To: foo2@bar.net To: foo2@bar.net
Subject: A simple example Subject: A simple example
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: "multipart/related"; boundary="boundary-example-1"; Content-Type: multipart/related; boundary="boundary-example-1";
type="text/html"; start=<foo3*foo1@bar.net> type="text/html"; start=<foo3*foo1@bar.net>
--boundary-example-1 --boundary-example-1
Content-Type: text/html;charset=US-ASCII Content-Type: text/html;charset=US-ASCII
Content-ID: <foo3*foo1@bar.net> Content-ID: <foo3*foo1@bar.net>
... text of the HTML document, which might contain a hyperlink ... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as: to the other body part, for example through a statement such as:
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif" <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
ALT="IETF logo"> ALT="IETF logo">
--boundary-example-1 --boundary-example-1
Content-Location: Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: "IMAGE/GIF" Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64 Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc... etc...
--boundary-example-1-- --boundary-example-1--
9.3 Example with relative URIs to an embedded GIF picture 9.3 Example with relative URIs to an embedded GIF picture
From: foo1@bar.net From: foo1@bar.net
To: foo2@bar.net To: foo2@bar.net
Subject: A simple example Subject: A simple example
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: "multipart/related"; boundary="boundary-example-1"; Content-Type: multipart/related; boundary="boundary-example-1";
type="text/html" type="text/html"
--boundary-example-1 --boundary-example-1
Content-Base: http://www.ietf.cnri.reston.va.us/ Content-Base: http://www.ietf.cnri.reston.va.us/
Content-Type: text/html; charset=ISO-8859-1 Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE
... text of the HTML document, which might contain a hyperlink ... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as: to the other body part, for example through a statement such as:
<IMG SRC="/images/ietflogo.gif" ALT="IETF logo"> <IMG SRC="/images/ietflogo.gif" ALT="IETF logo">
Example of a copyright sign encoded with Quoted-Printable: =A9 Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: &#168; Example of a copyright sign mapped onto HTML markup: &#168;
--boundary-example-1 --boundary-example-1
Content-Location: ietflogo.gif Content-Location: ietflogo.gif
Content-Base: http://www.ietf.cnri.reston.va.us/images/ Content-Base: http://www.ietf.cnri.reston.va.us/images/
; Note that the fact that the Content-Base comes after the ; Note that the fact that the Content-Base comes after the
; Content-Location within the same Content-Heading will not ; Content-Location within the same Content-Heading will not
; influence their interpretation ; influence their interpretation
Content-Type: "IMAGE/GIF" Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64 Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc... etc...
--boundary-example-1-- --boundary-example-1--
9.4 Example with relative URIs and no BASE available 9.4 Example with relative URIs and no BASE available
From: foo1@bar.net From: foo1@bar.net
To: foo2@bar.net To: foo2@bar.net
Subject: A simple example Subject: A simple example
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: "multipart/related"; boundary="boundary-example-1"; Content-Type: multipart/related; boundary="boundary-example-1";
type="text/html" type="text/html"
--boundary-example-1 --boundary-example-1
Content-Type: text/html; charset=ISO-8859-1 Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE
... text of the HTML document, which might contain a hyperlink ... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as: to the other body part, for example through a statement such as:
<IMG SRC="ietflogo.gif" ALT="IETF logo"> <IMG SRC="ietflogo.gif" ALT="IETF logo">
Example of a copyright sign encoded with Quoted-Printable: =A9 Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: &#168; Example of a copyright sign mapped onto HTML markup: &#168;
--boundary-example-1 --boundary-example-1
Content-Location: ietflogo.gif Content-Location: ietflogo.gif
Content-Type: "IMAGE/GIF" Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64 Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc... etc...
--boundary-example-1-- --boundary-example-1--
9.5 Example using a BASE on the Multipart 9.5 Example using a BASE on the Multipart
From: foo1@bar.net From: foo1@bar.net
To: foo2@bar.net To: foo2@bar.net
Subject: A simple example Subject: A simple example
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: "multipart/related"; boundary="boundary-example-1"; Content-Type: multipart/related; boundary="boundary-example-1";
type="text/html" type="text/html"
Content-Base: http://www.ietf.cnri.reston.va.us/ Content-Base: http://www.ietf.cnri.reston.va.us/
--boundary-example-1 --boundary-example-1
Content-Type: text/html; charset=ISO-8859-1 Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE
... text of the HTML document, which might contain a hyperlink ... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as: to the other body part, for example through a statement such as:
<IMG SRC="ietflogo.gif" ALT="IETF logo"> <IMG SRC="ietflogo.gif" ALT="IETF logo">
Example of a copyright sign encoded with Quoted-Printable: =A9 Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: &#168; Example of a copyright sign mapped onto HTML markup: &#168;
--boundary-example-1 --boundary-example-1
Content-Location: http://www.ietf.cnri.reston.va.us/ietflogo.gif Content-Location: http://www.ietf.cnri.reston.va.us/ietflogo.gif
Content-Type: "IMAGE/GIF" Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64 Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc... etc...
--boundary-example-1-- --boundary-example-1--
9.6 Example using CID URL and Content-ID header to an embedded GIF 9.6 Example using CID URL and Content-ID header to an embedded GIF
picture picture
From: foo1@bar.net From: foo1@bar.net
To: foo2@bar.net To: foo2@bar.net
Subject: A simple example Subject: A simple example
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: "multipart/related"; boundary="boundary-example-1"; Content-Type: multipart/related; boundary="boundary-example-1";
type="text/html" type="text/html"
--boundary-example-1 --boundary-example-1
Content-Type: text/html; charset=US-ASCII Content-Type: text/html; charset=US-ASCII
... text of the HTML document, which might contain a hyperlink ... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as: to the other body part, for example through a statement such as:
<IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo"> <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
--boundary-example-1 --boundary-example-1
Content-Location: CID:something@else ; this header is disregarded Content-Location: CID:something@else ; this header is disregarded
Content-ID: <foo4*foo1@bar.net> Content-ID: <foo4*foo1@bar.net>
Content-Type: "IMAGE/GIF" Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64 Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc... etc...
--boundary-example-1-- --boundary-example-1--
10. Content-Disposition header 10. Content-Disposition header
skipping to change at line 913 skipping to change at line 918
For the encoding of characters in HTML documents and other text For the encoding of characters in HTML documents and other text
documents into a MIME-compatible octet stream, the following mechanisms documents into a MIME-compatible octet stream, the following mechanisms
are relevant: are relevant:
- HTML [HTML2], [HTML-I18N] as an application of SGML [SGML] allows - HTML [HTML2], [HTML-I18N] as an application of SGML [SGML] allows
characters to be denoted by character entities as well as by numeric characters to be denoted by character entities as well as by numeric
character references (e.g. "Latin small letter a with acute accent" character references (e.g. "Latin small letter a with acute accent"
may be represented by "&aacute;" or "&#225;") in the HTML markup. may be represented by "&aacute;" or "&#225;") in the HTML markup.
- HTML documents, in common with other documents of the MIME - HTML documents, in common with other documents of the MIME
"Content-Type text", can be represented in MIME using one of several Content-Type "text", can be represented in MIME using one of several
character encodings. The MIME Content-Type "charset" parameter value character encodings. The MIME Content-Type "charset" parameter value
indicates the particular encoding used. For the exact meaning and indicates the particular encoding used. For the exact meaning and
use of the "charset" parameter, please see [MIME2] chapter 4. use of the "charset" parameter, please see [MIME2] chapter 4.
Note that the "charset" parameter refers only to the MIME character Note that the "charset" parameter refers only to the MIME character
encoding. For example, the string "&aacute;" can be sent in MIME encoding. For example, the string "&aacute;" can be sent in MIME
with "charset=US-ASCII", while the raw character "Latin small letter with "charset=US-ASCII", while the raw character "Latin small letter
a with acute accent" cannot. a with acute accent" cannot.
The above mechanisms are well defined and documented, and therefore not The above mechanisms are well defined and documented, and therefore not
skipping to change at line 953 skipping to change at line 958
Note that this might cause problems with integrity checks based on Note that this might cause problems with integrity checks based on
checksums, which might not be preserved when moving a document from the checksums, which might not be preserved when moving a document from the
HTTP to the MIME environment. If a document has to be converted in such HTTP to the MIME environment. If a document has to be converted in such
a way that a checksum integrity check becomes invalid, then this a way that a checksum integrity check becomes invalid, then this
integrity check header SHOULD be removed from the document. integrity check header SHOULD be removed from the document.
Other sources of problems are Content-Encoding used in HTTP but not Other sources of problems are Content-Encoding used in HTTP but not
allowed in MIME, and charsets that are not able to represent line allowed in MIME, and charsets that are not able to represent line
breaks as CRLF. A good overview of the differences between HTTP and breaks as CRLF. A good overview of the differences between HTTP and
MIME with regards to "Content-Type: Text" can be found in [HTTP], MIME with regards to Content-Type: "text" can be found in [HTTP],
appendix C. appendix C.
If the original document has line breaks in the canonical form (CRLF), If the original document has line breaks in the canonical form (CRLF),
then the document SHOULD remain unconverted so that integrity check then the document SHOULD remain unconverted so that integrity check
sums are not invalidated. sums are not invalidated.
A provider of HTML documents who wants his documents to be transferable A provider of HTML documents who wants his documents to be transferable
via both HTTP and SMTP without invalidating checksum integrity checks, via both HTTP and SMTP without invalidating checksum integrity checks,
should always provide original documents in the canonical form with should always provide original documents in the canonical form with
CRLF for line breaks. CRLF for line breaks.
skipping to change at line 1109 skipping to change at line 1114
[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext
Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996. Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.
[MD5] R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[MIDCID] E. Levinson: Message/External-Body Content-ID [MIDCID] E. Levinson: Message/External-Body Content-ID
Access"Message/External-Body Content-ID and Message-ID Access"Message/External-Body Content-ID and Message-ID
Uniform Resource Locators", draft-ietf-mhtml-cid-v2- Uniform Resource Locators", draft-ietf-mhtml-cid-v2-
00.txt, July 1997. 00.txt, July 1997.
[MIME1] N. Freed, N. Borenstein, "Multipurpose Internet Mail [MIME1] N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, December 1996. Bodies", RFC 2045, December 1996.
. .
[MIME-IMB] N. Freed & N. Borenstein [MIME-IMB] N. Freed & N. Borenstein
:: "Multipurpose Internet Mail Extensions (MIME) Part "Multipurpose Internet Mail Extensions (MIME) Part
One: Format of Internet Message Bedies". RFC 2045, One: Format of Internet Message Bedies". RFC 2045,
November 1996. November 1996.
[MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail [MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
December 1996. December 1996.
[MIME3] K. Moore, "MIME (Multipurpose Internet Mail Extensions) [MIME3] K. Moore, "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Part Three: Message Header Extensions for Non-ASCII
Text", RFC 2047, December 1996. Text", RFC 2047, December 1996.
skipping to change at line 1196 skipping to change at line 1202
Alex Hopmann Email: alexhop@microsoft.com Alex Hopmann Email: alexhop@microsoft.com
Microsoft Corporation Microsoft Corporation
3590 North First Street 3590 North First Street
Suite 300 Suite 300
San Jose San Jose
CA 95134 CA 95134
Working group chairman: Working group chairman:
Einar Stefferud <stef@nma.com> Einar Stefferud <stef@nma.com>
I.
 End of changes. 31 change blocks. 
54 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/