draft-ietf-mhtml-rev-04.txt   draft-ietf-mhtml-rev-05.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-04.txt Alexander Hopmann draft-ietf-mhtml-rev-05.txt Alexander Hopmann
IETF status to be: Proposed standard Microsoft Corporation IETF status to be: Proposed standard Microsoft Corporation
Revises: RFC 2110 Replaces: RFC 2110 Nick Shelness
Expires: May 1998 November 1997 Lotus Corporation
Expires: August 1998 February 1998
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.
skipping to change at line 28 skipping to change at line 29
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).
Copyright (C) The Internet Society 1998. All Rights Reserved.
Abstract Abstract
HTML [RFC 1866] defines a powerful means of specifying multimedia HTML [RFC 1866] defines a powerful means of specifying multimedia
documents. These multimedia documents consist of a text/html root documents. These multimedia documents consist of a text/html root
resource (object)and other subsidiary resources (image, video clip, resource (object)and other subsidiary resources (image, video clip,
applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) applet, etc. objects) referenced by Uniform Resource Identifiers (URIs)
within the text/html root resource. When an HTML multimedia document is within the text/html root resource. When an HTML multimedia document is
retrieved by a browser, each of these component resources is retrieved by a browser, each of these component resources is
individually retrieved in real time from a location, and using a individually retrieved in real time from a location, and using a
protocol, specified by each URI. protocol, specified by each URI.
In order to transfer a complete HTML multimedia document in a single e- In order to transfer a complete HTML multimedia document in a single
mail message, it is necessary to:- a) aggregate a text/html root e-mail message, it is necessary to: a) aggregate a text/html root
resource and all of the subsidiary resources it references into a resource and all of the subsidiary resources it references into a
single composite message structure, and b) define a means by which URIs single composite message structure, and b) define a means by which URIs
in the text/html root can reference subsidiary resources within that in the text/html root can reference subsidiary resources within that
composite message structure. composite message structure.
This document does both. It a) defines the use of a MIME This document a) defines the use of a MIME multipart/related structure
multipart/related structure to aggregate a text/html root resource and to aggregate a text/html root resource and the subsidiary resources it
the subsidiary resources it references, and b) specifies two MIME references, and b) specifies one MIME content-headers
content-headers (Content-Base and Content-Location) that allow URIs in (Content-Location) that allow URIs in a multipart/related text/html
a multipart/related text/html root body part to reference subsidiary root body part to reference subsidiary resources in other body parts of
resources in other body parts of the same multipart/related structure. the same multipart/related structure.
While initially designed to support e-mail transfer of complete multi- While initially designed to support e-mail transfer of complete
resource HTML multimedia documents, these conventions can also be multi-resource HTML multimedia documents, these conventions can also be
employed by other transfer protocols such as HTTP and FTP to retrieve a employed by other transfer protocols such as HTTP and FTP to retrieve a
complete multi-resource HTML multimedia document in a single transfer complete multi-resource HTML multimedia document in a single transfer
or for storage and archiving of complete HTML-documents. or for storage and archiving of complete HTML-documents.
Differences between this and a previous version of this standard, which Differences between this and a previous version of this standard, which
was published as RFC 2110, are summarized in chapter 13. was published as RFC 2110, are summarized in chapter 12.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Terminology 2. Terminology
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 MIME Content Header
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 URIs of MHTML aggregates
4.4 Encoding of URIs in MIME headers 4.4 Encoding and decoding of URIs in MIME header fields
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 URIs in text/html body parts 8.2 Resolution of URIs 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
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 an absolute URI to an embedded GIF picture 9.2 Example with an absolute URI to an embedded GIF picture
9.3 Example with a relative URI to an embedded GIF picture 9.3 Example with relative URIs to embedded GIF pictures
9.4 Example with a relative URI and no BASE available 9.4 Example with a relative URI and no BASE available
9.5 Example using a BASE on the Multipart 9.5 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
10. Content-Disposition header 9.6 Example showing permitted and forbidden references between
11. Character encoding issues and end-of-line issues nested body parts
12. Security Considerations 10. Character encoding issues and end-of-line issues
13. Differences as compared to the previous version of this proposed 11. Security Considerations
11.1 Security considerations not related to caching
11.2 Security considerations related to caching
12. Differences as compared to the previous version of this proposed
standard in RFC 2110 standard in RFC 2110
14. Copyright 13. Copyright
15. Acknowledgments 14. Acknowledgments
16. References 15. References
17. Author's Addresses 16. Author's Addresses
Mailing List Information Mailing List Information
To write contributions To write contributions
Further discussion on this document should be done through the Further discussion on this document should be done through the
mailing list MHTML@SEGATE.SUNET.SE. mailing list MHTML@SEGATE.SUNET.SE.
Comments on less important details may also be sent to the editor, Comments on less important details may also be sent to the editor,
Jacob Palme <jpalme@dsv.su.se>. Jacob Palme <jpalme@dsv.su.se>.
To subscribe To subscribe
To subscribe to this list, send a message to To subscribe to this mailing list, send a message to
LISTSERV@SEGATE.SUNET.SE LISTSERV@SEGATE.SUNET.SE
which contains the text which contains the text
SUB MHTML <your name (not your email address)> SUB MHTML <your name (not your email address)>
To unsubscribe To unsubscribe
To unsubscribe to this list, send a message to To unsubscribe from this list, send a message to
LISTSERV@SEGATE.SUNET.SE LISTSERV@SEGATE.SUNET.SE
which contains the text which contains the text
UNS MHTML UNS MHTML
To access mailing list archives To access mailing list archives
Archives of this list are available for bulk downloading by Archives of this list are available for bulk downloading by
anonymous ftp from anonymous ftp from
FTP://SEGATE.SUNET.SE/lists/mhtml/ FTP://SEGATE.SUNET.SE/lists/mhtml/
The archives are available for browsing from The archives are available for browsing from
HTTP://segate.sunet.se/archives/mhtml.html HTTP://segate.sunet.se/archives/mhtml.html
and in searchable format from and may be available in searchable format from
http://www.reference.com/cgi-bin/pn/ http://www.reference.com/cgi-bin/pn/listarch?list=MHTML@segate.sunet.se
listarch?list=MHTML@segate.sunet.se
Finally, the archives are available by email. Send a message to Finally, the archives are available by email. Send a message to
LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get a list 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 of the archive files, and then a new message "GET <file name>" to
retrieve the archive files. retrieve archive files.
More information More information
Information about the IETF work in developing this standard may Information about the IETF work in developing this standard may
also be available at URL: also be available at URL:
http://www.dsv.su.se/~jpalme/ietf/mhtml.html http://www.dsv.su.se/~jpalme/ietf/mhtml.html
A collection of test messages is available at A collection of test messages is available at
http://www.dsv.su.se/~jpalme/mimetest/MHTML-test-messages.html http://www.dsv.su.se/~jpalme/mimetest/MHTML-test-messages.html
1. Introduction 1. Introduction
There are a number of document formats (Hypertext Markup Language There are a number of document formats (Hypertext Markup Language
[HTML2], Portable Document format [PDF] and Virtual Reality Markup [HTML2], Extended Markup Language [XML], Portable Document format [PDF]
Language [VRML]) that specify documents consisting of a root resource and Virtual Reality Markup Language [VRML]) that specify documents
and a number of distinct subsidiary resources referenced by URIs within consisting of a root resource and a number of distinct subsidiary
that root resource. There is an obvious need to be able to send such resources referenced by URIs within that root resource. There is an
multi-resource documents in e-mail [SMTP], [RFC822] messages. obvious need to be able to send such multi-resource documents in e-mail
[SMTP], [RFC822] messages.
The standard defined in this document specifies how to aggregate such The standard defined in this document specifies how to aggregate such
multi-resource documents in MIME-formatted [MIME1 to MIME5] messages multi-resource documents in MIME-formatted [MIME1 to MIME5] messages
for precisely this purpose. for precisely this purpose.
While this specification was developed to satisfy the specific While this specification was developed to satisfy the specific
aggregation requirements of multi-resource HTML documents, it may also aggregation requirements of multi-resource HTML documents, it may also
be applicable to other multi-resource document representations linked be applicable to other multi-resource document representations linked
by URIs. While this is the case, there is no requirement that by URIs. While this is the case, there is no requirement that
implementations claiming conformance to this standard be able to handle implementations claiming conformance to this standard be able to handle
any URI linked document representations other than those whose root is any URI linked document representations other than those whose root is
HTML. HTML.
This aggregation into a single message of a root resource and the This aggregation into a single message of a root resource and the
subsidiary resources it references may also be applicable to other subsidiary resources it references may also be applicable to other
protocols such as HTTP or FTP, or to the archiving of complete web protocols such as HTTP or FTP, or to the archiving of complete web
pages as they appeared at a particular point in time. pages as they appeared at a particular point in time.
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 strongly recommended to some implementation problems. Implementers are strongly recommended to
read this informational RFC when developing implementations of this read this informational RFC when developing implementations of this
standard. You can find it through URL standard. You can find it through URL
http://www.dsv.su.se/~jpalme/ietf/mhtml.html. http://www.dsv.su.se/~jpalme/ietf/mhtml.html.
This standard specifies that body parts to be referenced can be
identified either by a Content-ID (containing a Message-ID value) or by
a Content-Location (containing an arbitrary URL). The reason why this
standard does not only recommend the use of Content-ID-s is that it
should be possible to forward existing web pages via e-mail without
having to rewrite the source text of the web pages. Such rewriting has
several disadvantages, one of them that security checksums will
probably be invalidated.
2. Terminology 2. Terminology
2.1 Conformance requirement terminology 2.1 Conformance requirement terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [IETF-TERMS]. document are to be interpreted as described in [IETF-TERMS].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST requirements for the protocols it implements. An of the MUST requirements for the protocols it implements. An
skipping to change at line 210 skipping to change at line 222
2.2 Other terminology 2.2 Other terminology
Most of the terms used in this document are defined in other RFCs. Most of the terms used in this document are defined in other RFCs.
Absolute URI, See Relative Uniform Resource Locators [RELURL]. Absolute URI, See Relative Uniform Resource Locators [RELURL].
AbsoluteURI AbsoluteURI
CID See Message/External Body Content-ID [MIDCID]. CID See Message/External Body Content-ID [MIDCID].
Content-Base See section 4.2 below. 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-ID See Message/External Body Content-ID [MIDCID].
Content-Location MIME message or content part header with the URI of Content-Location MIME message or content part header with one URI of
the MIME message or content part body, defined in the MIME message or content part body, defined in
section 4.3 below. section 4.2 below.
Content-Transfer- Conversion of a text into 7-bit octets as specified Content-Transfer-Enco Conversion of a text into 7-bit octets as specified
Encoding in [MIME1] chapter 6. ding in [MIME1] chapter 6.
CR See [RFC822]. CR See [RFC822].
CRLF See [RFC822]. CRLF See [RFC822].
Displayed text The text shown to the user reading a document with Displayed text The text shown to the user reading a document with
a web browser. This may be different from the HTML a web browser. This may be different from the HTML
markup, see the definition of HTML markup below. markup, see the definition of HTML markup below.
Header Field in a message or content heading specifying Header Field in a message or content heading specifying
skipping to change at line 273 skipping to change at line 286
URL See RFC 1738 [URL]. URL See RFC 1738 [URL].
URL, relative See Relative Uniform Resource Locators [RELURL]. URL, relative See Relative Uniform Resource Locators [RELURL].
VRML See Virtual Reality Markup Language [VRML]. VRML See Virtual Reality Markup Language [VRML].
3. Overview 3. Overview
An aggregate document is a MIME-encoded message that contains a root An aggregate document is a MIME-encoded message that contains a root
resource (object) as well as other resources that are required to resource (object) as well as other resources linked to it via URIs.
represent that document (inline pictures, style sheets, applets, etc.). These other resources may be required to display a multimedia document
It is important to keep in mind that aggregate documents need to based on the root resource (inline pictures, style sheets, applets,
satisfy the differing needs of several audiences. This standard can etc.), or be the root resources of other multimedia documents. It is
also be used to send sets of linked documents which are not shown important to keep in mind that aggregate documents need to satisfy the
simultaneously, and where the user can use links to move between them. differing needs of several audiences.
Mail sending agents might send aggregate documents as an encoding of Mail sending agents might send aggregate documents as an encoding of
normal day-to-day electronic mail. Mail sending agents might also send normal day-to-day electronic mail. Mail sending agents might also send
aggregate documents when a user wishes to mail a particular document aggregate documents when a user wishes to mail a particular document
from the web to someone else. Finally mail sending agents might send from the web to someone else. Finally mail sending agents might send
aggregate documents as automatic responders, providing access to WWW aggregate documents as automatic responders, providing access to WWW
resources for non-IP connected clients. Also with other protocols such resources for non-IP connected clients. Also with other protocols such
as HTTP or FTP, there may sometimes be a need to retrieve aggregate as HTTP or FTP, there may sometimes be a need to retrieve aggregate
documents. Receiving agents also have several differing needs. Some documents. Receiving agents also have several differing needs. Some
receiving agents might be able to receive an aggregate document and receiving agents might be able to receive an aggregate document and
display it just as any other text content type would be displayed. display it just as any other text content type would be displayed.
Others might have to pass this aggregate document to a browsing Others might have to pass this aggregate document to a browsing
program, and provisions need to be made to make this possible. program, and provisions need to be made to make this possible.
Finally several other constraints on the problem arise. It is important Finally several other constraints on the problem arise. It is important
that it be possible for a document to be signed and for it to be that it be possible for a document to be signed and for it to be
transmitted and displayed without breaking the message integrity (MIC) transmitted and displayed without breaking the message integrity (MIC)
check that is part of the signature. checksum that is part of the signature.
4. The Content-Location and Content-Base MIME Content Headers 4. The Content-Location MIME Content Header
4.1 MIME content headers 4.1 MIME content headers
In order to resolve URI references to resources in other body parts, In order to resolve URI references to resources in other body parts,
two MIME content headers are defined, Content-Location and one MIME content headers is defined, Content-Location. This header can
Content-Base. Both of these headers can occur in any message or content occur in any message or content heading.
heading, and will then be valid within this heading and over its
immediate content. If they occur in multipart or message headings, they
apply to its body parts only in that they can be used to derive a base
for relative URIs within those body parts, and only if no such base is
provided in the body part itself or in multipart or message headings
closer in scope to the body part.
These two headers may occur on any message or content heading, but The syntax for this header is, using the syntax definition tools from
their usage for handling hyperlinks between body parts in a message [ABNF]:
SHOULD only occur between body parts within the same multipart/related
structure.
At present only those URIs which are URLs are affected by these quoted-pair = ("\" text)
headers, but it is anticipated that in future other forms of URIs maybe
affected.
The syntax for these headers is, using the syntax definition tools from text = %d1-9 / ; Characters excluding CR and LF
[RFC822]: %d11-12 /
%d14-127
content-location = "Content-Location:" WSP = SP / HTAB ; Whitespace characters
( absoluteURI | relativeURI )
content-base = "Content-Base:" absoluteURI 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 where URI is restricted to the syntax for URLs as defined in Uniform
Resource Locators [URL] until IETF specifies other kinds of URIs. Resource Locators [URL] until IETF specifies other kinds of URIs.
4.2 The Content-Location Header 4.2 The Content-Location Header
A Content-Location header specifies an URI that labels the content of a A Content-Location header specifies an URI that labels the content of a
body part in whose heading it is placed. Its value CAN be an absolute body part in whose heading it is placed. Its value CAN be an absolute
or a relative URI. Any URI or URL scheme may be used, but use of or a relative URI. Any URI or URL scheme may be used, but use of
non-standardized URI or URL schemes might entail some risk that non-standardized URI or URL schemes might entail some risk that
recipients cannot handle them correctly. recipients cannot handle them correctly.
An 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.
An URI in a Content-Location header need not refer to an resource which An URI in a Content-Location header need not refer to an resource which
is globally available for retrieval using this URI (after resolution of is globally available for retrieval using this URI (after resolution of
relative URIs). However, URI-s in Content-Location headers (if relative URIs). However, URI-s in Content-Location headers (if
absolute, or resolvable to absolute URIs) SHOULD still be globally absolute, or resolvable to absolute URIs) SHOULD still be globally
unique. unique.
A Content-Location header can also be used to label a resource which is A Content-Location header can thus be used to label a resource which is
not retrievable by some or all recipients of a message. For example a not retrievable by some or all recipients of a message. For example a
Content-Location header may label an object which is only retrievable Content-Location header may label an object which is only retrievable
using this URI in a restricted domain, such as within a using this URI in a restricted domain, such as within a
company-internal web space. A Content-Location header can even contain company-internal web space. A Content-Location header can even contain
a fictitious URI. Such an URI need not be globally unique. a fictitious URI. Such an URI need not be globally unique.
There MUST only be a single Content-Location header in each message or A single Content-Location header field is allowed in any message or
content heading, whose value is a single URI. Note, however, that both content heading, in addition to a Content-ID header (as specified in
one Content-Location and one Message-ID or Content-ID header are [MIME1]) and, in Message headings, a Message-ID (as specified in
allowed in a message or content heading. In such a case, these will [RFC822]). All of these constitute different, equally valid body part
indicate two different, equally valid references to a body part, and labels, and any of them may be used to satisfy a reference to a body
either of them may be used to refer to this body part. part. Multiple Content-Location header fields in the same message
heading are not allowed.
Example of a multipart/related structure containing body parts with Example of a multipart/related structure containing body parts with
both Content-Location and Content-ID labels: both Content-Location and Content-ID labels:
Content-Type: "multipart/related"; boundary="boundary-example"; Content-Type: "multipart/related"; boundary="boundary-example";
type="text/html" type="text/html"
--boundary-example --boundary-example
Content-Type: text/html; charset=US-ASCII Content-Type: text/html; charset=US-ASCII
... ... <IMG SRC="fiction1/fiction2"> ... ... ... ... <IMG SRC="fiction1/fiction2"> ... ...
... ... <IMG SRC="cid:97116092811xyz*foo.bar.net"> ... ... ... ... <IMG SRC="cid:97116092811xyz@foo.bar.net"> ... ...
--boundary-example --boundary-example
Content-Type: image/gif Content-Type: image/gif
Content-ID: <97116092511xyz*foo.bar.net> Content-ID: <97116092511xyz@foo.bar.net>
Content-Location: fiction1/fiction2 Content-Location: fiction1/fiction2
--boundary-example --boundary-example
Content-Type: image/gif Content-Type: image/gif
Content-ID: <97116092811xyz*foo.bar.net> Content-ID: <97116092811xyz@foo.bar.net>
Content-Location: fiction1/fiction3 Content-Location: fiction1/fiction3
--boundary-example-- --boundary-example--
4.3 The Content-Base header 4.3 URIs of MHTML aggregates
A Content-Base header provides a base for resolving relative URIs
occurring in other header fields in the same content heading, relative
URIs occurring in other header fields nested within its content that
lack their own base, or relative URIs occurring in body parts nested
within its content that do not contain an embedded base specification -
for example, an HTML BASE element. The value of a Content-Base header
MUST be an absolute URI.
Example showing which Content-Base is valid where:
Content-Type: "multipart/related"; boundary="boundary-example";
type="text/html"; start=<foo2*foo3@bar2.net>
; A Content-Base header is allowed here, and can be used
; for resolution of relative URL-s in Part 1 and Part 2,
; if these did not have any absolute base of their own.
; However, both part 1 and part 2 below have an absolute
; base, in part 1 through an absolute Content-Location header,
; in part 2 through a Content-Base header, and thus a Content-
; base up here would not be used for resolution of relative
; URLs within the body parts 1 and 2.
--boundary-example
Part 1:
Content-Type: text/html; charset=US-ASCII
Content-ID: <foo2*foo3@bar2.net>
Content-Location: http://www.ietf.cnri.reston.va.us/foo1.bar1
; Since this Content-Location contains an absolute URL, it
; does not need to be resolved using any Content-Base header.
; A combination of a Content-Location with a relative URL
; and a Content-Base with an absolute URL would also be valid,
; as well as only a Content-Location with a relative URL
; and resolved through the Content-Base in the surrounding
; multipart heading.
<FRAME NAME=topwindow src="/frames/foo2.bar2">
--boundary-example
Part 2:
Content-Type: text/html; charset=US-ASCII
Content-ID: <foo4*foo5@bar2.net>
Content-Location: foo2.bar2 ; The Content-Base below applies to
; this relative URI
Content-Base: http://www.ietf.cnri.reston.va.us/frames/
<A HREF="http://www.ietf.cnri.reston.va.us/foo1.bar1"> The URI of an MHTML aggregate is not the same as the URI of its root.
To top window </A> The URI of its root will directly retrieve only the root resource
itself, even if it may cause a web browser to 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.
--boundary-example-- When an URI referring to an MHTML aggregate is used to retrieve this
aggregate, the set of resources retrieved can be different from the set
of resources retrieved using the Content-Locations of its parts. For
example, retrieving an MHTML aggregate may return an old version, while
retrieving the root URI and its in-line linked objects may return a
newer version.
4.4 Encoding of URIs in MIME headers 4.4 Encoding and decoding of URIs in MIME header fields
4.4.1 Handling of URIs containing inappropriate characters 4.4.1 Encoding 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. If such a URI occurs, all
that can be taken when encountering such a URI as the text to be placed spaces and other illegal characters in it must be encoded using one of
in a Content-Location or Content-Base header: 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
(a) In some situations, an implementation might be able to replace the the [MIME3] encoding in the heading before comparing URIs in body text
URI with one that can be sent directly. This might be accomplished, to URIs in Content-Location headers.
for example, by using the encoding method of [URL] to replace
inappropriate characters within the URI with ones encoded using the
"%nn" encoding. This replacement MUST in that case be done both in
the header and in the text/html body part that contains the URI
references the header. Since the change is done in both places, a
receiving agent need not decode it, and MUST NOT decode the [URL]-
encoding before matching URIs to body parts.
(b) The URI might be encoded using the method described in [MIME3].
This replacement 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.
With method (b), the charset parameter value "US-ASCII" SHOULD be used The charset parameter value "US-ASCII" SHOULD be used if the URI
if the URI contains no octets outside of the 7-bit range. If such contains no octets outside of the 7-bit range. If such octets are
octets are present, the correct charset parameter value (derived e.g. present, the correct charset parameter value (derived e.g. from
from information about the HTML document the URI was found in) SHOULD information about the HTML document the URI was found in) SHOULD be
be used. If this cannot be safely established, the value "UKNOWN-8BIT" used. If this cannot be safely established, the value "UNKNOWN-8BIT"
[RFC 1428] MUST be used. [RFC 1428] MUST be used.
Note, that for the matching of URIs in text/html body parts to URIs in Note, that for the matching of URIs in text/html body parts to URIs in
Content-Location headers, the value of the charset parameter is Content-Location headers, the value of the charset parameter is
irrelevant, but that it may be relevant for other purposes, and that irrelevant, but that it may be relevant for other purposes, and that
incorrect labeling MUST, therefore, be avoided. Warning: Irrelevance of incorrect labeling MUST, therefore, be avoided. Warning: Irrelevance of
the charset parameter may not be true in the future, if different the charset parameter may not be true in the future, if different
character encodings of the same non-English filename are used in HTML. character encodings of the same non-English filename are used in HTML.
Caution should be taken in using method (a), since, in general, this
encoding cannot be applied safely to characters that are used for
reserved purposes within the URI scheme. In addition, changing the HTML
body which contains the URI might invalidate a message integrity check.
For these reasons, this method SHOULD only be used if it is performed
in cooperation with the author/owner of the documents involved.
4.4.2 Folding of long URIs 4.4.2 Folding of long URIs
Since MIME header fields have a limited length and long URIs can result Since MIME header fields have a limited length and long URIs can result
in Content-Location and Content-Base headers that exceed this length , in Content-Location that exceed this length, Content-Location headers
Content-Location and Content-Base headers may have to be folded. may have to be folded.
Encoding as discussed in clause 4.4.1 MUST be done before such folding. Encoding as discussed in clause 4.4.1 MUST be done before such folding.
This MUST include encoding of space characters, if any. After that, the After that, the folding can be done, using the algorithm defined in
folding can be done, using the algorithm defined in [URLBODY] section [URLBODY] section 3.1.
3.1.
4.4.3 Unfolding and decoding of received URLs in MIME header fields
Upon receipt, folded MIME header fields should be unfolded, and then
any MIME encoding should be removed, to retrieve the original URI.
5. Base URIs for resolution of relative URIs 5. Base URIs for resolution of relative URIs
Relative URIs inside the contents of MIME body parts are resolved Relative URIs inside the contents of MIME body parts are resolved
relative to a base URI using the methods for resolving relative URIs relative to a base URI using the methods for resolving relative URIs
described in [RELURL]. In order to determine this base URI, the described in [RELURL]. In order to determine this base URI, the
first-applicable method in the following list applies. first-applicable method in the following list applies.
(a) There is a base specification inside the MIME body part containing (a) There is a base specification inside the MIME body part containing
the relative URI which resolves relative URIs into absolute URIs. the relative URI which resolves relative URIs into absolute URIs.
For example, HTML provides the BASE element for this purpose. For example, HTML provides the BASE element for this purpose.
(b) There is a Content-Base header (as defined in section 4.2), in the (b) There is a Content-Location header in the immediately surrounding
immediately surrounding content heading, specifying the base to be heading of the body part and it contains an absolute URI. This URI
used. can serve as a base in the same way as a requested URI can serve as
a base for relative URIs within a file retrieved via HTTP [HTTP].
(c) There is a Content-Location header in the immediately surrounding (c) If necessary, step (b) can be repeated recursively to find a
heading of the body part which contains an absolute URI. This URI suitable Content-Location header in a surrounding multi-part and
can serve as a base in the same way as a requested URI can message heading.
serve as a base for relative URIs within a file retrieved via HTTP
[HTTP].
(d) Step (b) and (c) can be repeated recursively to find a suitable (d) If the MIME object is returned in a HTTP response, use the
Content-Base or Content-Location header in a surrounding multi-part URI used to initiate the request
and message heading. Note, that a base from an absolute
Content-Location in an inner heading takes precedence over a base
from a Content-Base or a Content-Location in a surrounding heading.
(e) When the methods above do not yield an absolute URI, a base URL of (e) When the methods above do not yield an absolute URI, a base URL of
"this_message:/" MUST be employed. This base URL has been defined "this_message:/" MUST be employed. This base URL has been defined
for the sole purpose of resolving relative references within a for the sole purpose of resolving relative references within a
multipart/related structure when no other base URI exists. multipart/related structure when no other base URI is specified.
This is also described in other words in section 8.2 below. This is also described in other words in section 8.2 below.
6. Sending documents without linked objects 6. Sending documents without linked objects
If a text/html resource (object) is sent without subsidiary resources , If a text/html resource (object) is sent without subsidiary resources ,
to which it is linked, it MAY be sent by itself. In this case, to which it refers, it MAY be sent by itself. In this case, embedding
embedding it in a multipart/related structure is not necessary. it in a multipart/related structure is not necessary.
Such a text/html resource may contain no URIs, or URIs which the Such a text/html resource may either contain no URIs, or URIs which the
recipient is expected to retrieve (if possible) via a URI specified recipient is expected to retrieve (if possible) via a URI specified
protocol. Although not normal, a text/html resource may be sent with protocol. A text/html resource may also be sent with unresolvable links
unresolvable links, for example when two authors exchange drafts of in special cases, such as when two authors exchange drafts of
unfinished resources. unfinished resources.
Inclusion of URIs referencing resources which the recipient has to Inclusion of URIs referencing resources which the recipient has to
retrieve via an URI specified protocol may not work for some retrieve via an URI specified protocol may not work for some
recipients. This is because not all e-mail recipients have full recipients. This is because not all e-mail recipients have full
internet connectivity, or because URIs which work for a sender will not Internet connectivity, or because URIs which work for a sender will not
work for a recipient. This occurs, for example, when an URI refers to a work for a recipient. This occurs, for example, when an URI refers to a
resource within a company-internal network that is not accessible from resource within a company-internal network that is not accessible from
outside the company. outside the company.
Note that text/html resources containing URIs that reference resources
that a recipient cannot retrieve MAY be sent, although this is
discouraged. For example, two persons developing a new Web page may
exchange incomplete versions of that page.
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 URIs and If a message contains one or more MIME body parts containing URIs and
also contains as separate body parts, resources, to which these URIs also contains as separate body parts, resources, to which these URIs
(as defined, for example, in HTML 2.0 [HTML2]) refer, then this whole (as defined, for example, in HTML 2.0 [HTML2]) refer, then this whole
set of body parts (referring body parts and referred-to body parts) set of body parts (referring body parts and referred-to body parts)
SHOULD be sent within a multipart/related structure as defined in SHOULD be sent within a multipart/related structure as defined in
[REL]. [REL].
Even though Content-Location and Content-Base headers can occur in a Even though headers can occur in a message that lacks an associated a
message that lacks an associated a multipart/related structure, this multipart/related structure, this standard only covers their use for
standard only covers their use for resolution of URIs between body resolution of URIs between body parts inside a multipart/related
parts inside a single multipart/related structure. This standard does structure. This standard does cover the case where a resource in a
not cover URIs from one multipart/related structure to another nested multipart/related structure contains URIs that reference MIME
multipart/related structure in a message containing multiple body parts in another multipart/related structure, in which it is
multipart/related objects either in parallel or nested one within the enclosed. This standard does not cover the case where a resource in a
other. multipart/related structure contains URIs that reference MIME body
parts in another parallel or nested multipart/related structure, or in
another MIME message, even if methods similar to those described in
this standard are used. Implementers who employ such URIs are warned
that receiving agents implementing this standard may not be able to
process such references.
When the start body part of a multipart/related structure is an atomic When the start body part of a multipart/related structure is an atomic
object, such as a text/html resource, it SHOULD be employed as the root object, such as a text/html resource, it SHOULD be employed as the root
resource of that multipart/related structure. When the start body part resource of that multipart/related structure. When the start body part
of a multipart/related structure is a multipart/alternative structure, of a multipart/related structure is a multipart/alternative structure,
and that structure contains at least one alternative body part which is and that structure contains at least one alternative body part which is
a suitable atomic object, such as a text/html resource, then that body a suitable atomic object, such as a text/html resource, then that body
part SHOULD be employed as the root resource of the aggregate document. part SHOULD be employed as the root resource of the aggregate document.
Implementors are warned, however, that some receiving agents treat Implementers are warned, however, that some receiving agents treat
multipart/alternative as if it had been multipart/mixed (even though multipart/alternative as if it had been multipart/mixed (even though
MIME [MIME1] requires support for multipart/alternative). MIME [MIME1] requires support for multipart/alternative).
[REL] specifies that a type parameter is mandatory in a "Content-Type: [REL] specifies that a type parameter is mandatory in a "Content-Type:
multipart/related" header, and requires that it be employed to specify multipart/related" header, and requires that it be employed to specify
the type of the multipart/related start object. Thus, the type the type of the multipart/related start object. Thus, the type
parameter value shall be "multipart/alternative", when the start part parameter value shall be "multipart/alternative", when the start part
is of "Content-type multipart/alternative", even if the actual root is of "Content-type multipart/alternative", even if the actual root
resource is of type "text/html". In addition, if the multipart/related resource is of type "text/html". In addition, if the multipart/related
start object is not the first body part in a multipart/related start object is not the first body part in a multipart/related
skipping to change at line 643 skipping to change at line 597
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, if this is verify the documents against their WWW counterpoints, if this is
appropriate. appropriate.
In certain cases this will not work - for example, if a resource In certain cases this will not work - for example, if a resource
contains URIs as parameters to objects and applets. In such a case, it contains URIs as parameters to objects and applets. In such a case, it
might be better to rewrite the document before sending it. This problem might be better to rewrite the document before sending it. This problem
is discussed in more detail in the informational RFC which will be is discussed in more detail in the informational RFC which will be
published as a supplement to this standard. published as a supplement to this standard.
This standard does not cover the case where a resource in a
multipart/related structure contains URIs that reference MIME body
parts outside of the current multipart/related structure or in other
MIME messages, even if methods similar to those described in this
standard are used. Implementors who employ such URIs are warned that
receiving agents implementing this standard may not be able to process
them.
Within a multipart/related structure, each body part MUST have, if Within a multipart/related structure, each body part MUST have, if
assigned, a different Content-ID header value and a Content-Location assigned, a different Content-ID header value and a Content-Location
header values which resolves to a different URI. header field values which resolve to a different URI.
Two body parts in the same multipart/related structure can have the Two body parts in the same multipart/related structure can have the
same relative Content-Location header value, only if when resolved to same relative Content-Location header value, only if when resolved to
absolute URIs in combination with Content-Base header values, they are absolute URIs they become different.
then 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 URIs that A body part, such as a text/html body part, may contain URIs that
reference resources which are included as body parts in the same reference resources which are included as body parts in the same
message -- in detail, as body parts within the same multipart/related message -- in detail, as body parts within the same multipart/related
structure. Often such URI linked resources are meant to be displayed structure. Often such URI linked resources are meant to be displayed
inline to the viewer of the referencing body part; for example, objects inline to the viewer of the referencing body part; for example, objects
referenced with the SRC attribute of the IMG element in HTML 2.0 referenced with the SRC attribute of the IMG element in HTML 2.0
[HTML2]. New elements and attributes with this property are proposed in [HTML2]. New elements and attributes with this property are proposed in
the ongoing development of HTML (examples: applet, frame, profile, the ongoing development of HTML (examples: applet, frame, profile,
OBJECT, classid, codebase, data, SCRIPT). A sender might also want to OBJECT, classid, codebase, data, SCRIPT). A sender might also want to
send a set of HTML documents which the reader can traverse, and which send a set of HTML documents which the reader can traverse, and which
are related with the attribute href of the A element. are related with the attribute href of the A element.
In order to send such messages, there is a need to specify how a URI in If a user retrieves and displays a web page formed from a text/html
one body part can reference a resource in another body part. resource, and the subsidiary resources it references, and merely saves
the text/html resource, that user may not at a later time be able to
retrieve and display the web page as it appeared when saved. The format
described in this standard can be used to archive and retrieve all of
the resources required to display the web page, as it originally
appeared at a certain moment of time, in one aggregate file.
In order to send or store complete such messages, there is a need 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 8.2 Resolution of URIs in text/html body parts
The resolution of URIs in text/html body parts is performed in the The resolution of URIs in text/html body parts is performed in the
following way: 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
[URL]. Example: Do not transform "a%2eb/c%20d" into "a/b/c d". [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 (b) Remove all MIME encodings, such as content-transfer encoding and
header encodings as defined in MIME part 3 [MIME3] Do NOT however header encodings as defined in MIME part 3 [MIME3] Do NOT however
translate character encodings of the kind described in [URL]. translate character encodings of the kind described in [URL].
Example: Do not transform "a%2eb/c%20d" into "a/b/c d". 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 (c) Try to resolve all relative URIs in the HTML content and in
Content-Location headers using the procedure described in chapter 5 Content-Location headers using the procedure described in chapter
above. The result of this resolution can be an absolute URI, or a 5 above. The result of this resolution can be an absolute URI,
fictitious absolute URI with the base "this_message:/" as specified or an absolute URI with the base "this_message:/" as specified
in chapter 5. in chapter 5.
(d) For each referencing URI in a text/html body part, compare the (d) For each referencing URI in a text/html body part, compare the
value of the referencing URI after resolution as described in (a) value of the referencing URI after resolution as described in (a)
and (b), with the URI derived from Content-ID and Content-Location and (b), with the URI derived from Content-ID and Content-Location
headers for other body parts within the same Multipart/related headers for other body parts within the same Multipart/related
structure. If the strings are identical, octet by octet, then the
referencing URI references that body part. This comparison will Multipart/related structure. If the strings are identical, octet by
only succeed if the two URIs are identical. This means that if one octet, then the referencing URI references that body part. This
of the two URIs to be compared was a fictitious absolute URI with comparison will only succeed if the two URIs are identical. This
the base"this_message:/", the other must also be such a fictitious means that if one of the two URIs to be compared was a fictitious
absolute URI, and not resolvable to a real absolute URI. absolute URI with the base"this_message:/", 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 (e) If (d) fails, try to retrieve the URI referenced resource
hyperlink through ordinary Internet lookup. Resolution of URIs of hyperlink through ordinary Internet lookup. Resolution of URIs of
the URL-types "mid" or "cid" to other content-parts, outside the the URL-types "mid" or "cid" to other content-parts, outside the
same multipart/related structure, or in other separately sent same multipart/related structure, or in other separately sent
messages, is not covered by this standard, and is thus neither messages, is not covered by this standard, and is thus neither
encouraged nor forbidden. encouraged nor forbidden.
8.3 Use of the Content-ID header and CID URLs 8.3 Use of the Content-ID header and CID URLs
When CID (Content-ID) URLs as defined in [URL] and [MIDCID] are used to When URIs employing a CID (Content-ID) scheme as defined in [URL] and
reference other body parts, they MUST only be matched against [MIDCID] are used to reference other body parts in an MHTML
multipart/related structure, they MUST only be matched against
Content-ID header values, and not against Content-Location header with Content-ID header values, and not against Content-Location header with
CID: values. Thus, even though the following two headers are CID: values. Thus, even though the following two headers are identical
identical in meaning, only Content-ID value will be matched, and the in meaning, only the Content-ID value will be matched, and the
Content-Location value will be ignored. Content-Location value will be ignored.
Content-ID: <foo@bar.net> Content-ID: <foo@bar.net>
Content-Location: CID: foo@bar.net Content-Location: CID: foo@bar.net
Note: Content-IDs MUST be globally unique [MIME1]. It is thus not 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 permitted to make them unique only within a message or within a single
multipart/related structure. multipart/related structure.
8.4 Conformance requirement on receipt
An e-mail system which claims conformance to this standard MUST support
receipt of multipart/related structures (as defined in section 7) with
URIs referencing body parts using both the Content-Location (as defined
in section 8.2) and the Content-ID method (as defined in section 8.3).
9. Examples 9. Examples
Warning: If there is a contradiction between the explanatory text and Warning: The examples are provided for illustrative purposes only. If
the examples in this standard, then the explanatory text, not the there is a contradiction between the explanatory text and the examples
examples are normative. 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 9.1 Example of a HTML body without included linked objects
The first example is the simplest form of an HTML email message. This The first example is the simplest form of an HTML email message. This
message does not contain an aggregate HTML object, but simply a message message does not contain an aggregate HTML object, but simply a message
with a single HTML body part. This body part contains a URI but the with a single HTML body part. This body part contains a URI but the
messages does not contain the resource referenced by that URI. To messages does not contain the resource referenced by that URI. To
retrieve the resource referenced by the URI the receiving client would retrieve the resource referenced by the URI the receiving client would
need either IP access to the Internet, or an electronic mail web need either IP access to the Internet, or an electronic mail web
gateway. gateway.
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: text/html; charset=US-ASCII Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
<HTML> <HTML>
<head></head> <head></head>
<body> <body>
<h1>Hi there!</h1> <h1>Acute accent</h1>
An example of an HTML message.<p> The following two lines look have the same screen rendering:<p>
Try clicking <a href="http://www.resnova.com/">here.</a><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> </body></HTML>
9.2 Example with an absolute URI to an embedded GIF picture 9.2 Example with an absolute URI to an embedded GIF picture
The second example is an HTML message which includes a single image,
referenced using the Content-Location mechanism.
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"; Content-Type: multipart/related; boundary="boundary-example";
type="text/html"; start=<foo3*foo1@bar.net> type="text/html"; start=<foo3@foo1@bar.net>
--boundary-example --boundary-example
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 URI ... text of the HTML document, which might contain a URI
referencing a resource in referencing a resource in another body part, for example
another body part, for example through a statement such as: 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 --boundary-example
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-- --boundary-example--
9.3 Example with a relative URI to an embedded GIF picture 9.3 Example with relative URIs to embedded GIF pictures
In this example, a Content-Location header field in the outermost
heading will be a base to all relative URLs, also inside the HTML text
being sent.
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-Location: http://www.ietf.cnri.reston.va.us/
Content-Type: multipart/related; boundary="boundary-example"; Content-Type: multipart/related; boundary="boundary-example";
type="text/html" type="text/html"
--boundary-example --boundary-example
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 URI ... text of the HTML document, which might contain URIs
referencing a resource in referencing resources in other body parts, for example through
another body part, for example through a statement such as: statements such as:
<IMG SRC="/images/ietflogo.gif" ALT="IETF logo">
<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 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 --boundary-example
Content-Location: Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif
; Note - Absolute Content-Location does not require a
; base
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
Content-Location: ietflogo2.gif
; Note - Relative Content-Location is resolved by base
; specified in the Multipart/Related 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-- --boundary-example--
9.4 Example with a relative URI and no BASE available 9.4 Example with a relative URI 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"; Content-Type: multipart/related; boundary="boundary-example";
type="text/html" type="text/html"
--boundary-example --boundary-example
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 URI ... text of the HTML document, which might contain a URI
referencing a resource in referencing a resource in another body part, for example
another body part, for example through a statement such as: 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 --boundary-example
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-- --boundary-example--
9.5 Example using a BASE on the Multipart 9.5 Example using CID URL and Content-ID header 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"; Content-Type: multipart/related; boundary="boundary-example";
type="text/html" type="text/html"
Content-Base: http://www.ietf.cnri.reston.va.us/
--boundary-example --boundary-example
Content-Type: text/html; charset=ISO-8859-1 Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
... text of the HTML document, which might contain a URI ... text of the HTML document, which might contain a URI
referencing a resource in referencing a resource in another body part, for example
another body part, for example through a statement such as: through a statement such as:
<IMG SRC="ietflogo.gif" ALT="IETF logo"> <IMG SRC="cid:foo4@foo1@bar.net" 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 --boundary-example
Content-Location: ietflogo.gif Content-Location: CID:something@else ; this header is disregarded
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-- --boundary-example--
9.6 Example using CID URL and Content-ID header to an embedded GIF 9.6 Example showing permitted and forbidden references between nested
picture body parts
This example shows in which cases references are allowed between
multiple multipart/related body parts in a message.
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"; Content-Type: multipart/related; boundary="boundary-example-1";
type="text/html" type="text/html"
--boundary-example --boundary-example-1
Content-Type: text/html; charset=US-ASCII Content-Type: text/html; charset=US-ASCII
Content-ID: <foo3@foo1@bar.net>
... text of the HTML document, which might contain a URI The image reference below will be resolved with the image
referencing a resource in in the next body part.
another body part, for example through a statement such as: <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
<IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo"> ALT="IETF logo with white background">
--boundary-example The image reference below cannot be resolved within this
Content-Location: CID:something@else ; this header is disregarded MIME message, since it contains a reference from an outside
Content-ID: <foo4*foo1@bar.net> 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-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64 Content-Transfer-Encoding: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc... etc...
--boundary-example-- --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>
10. Content-Disposition header 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">
Note the specification in [REL] on the relations between The image reference below will be resolved with the image
Content-Disposition and multipart/related. inside the current nested multipart/related below.
<IMG SRC=images/ietflogo2e.gif"
ALT="IETF logo with transparent background">
11. Character encoding issues and end-of-line issues --boundary-example-2
Content-Location: http:images/ietflogo2e.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/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
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.
skipping to change at line 970 skipping to change at line 1031
handling any combinations of these mechanisms. handling any combinations of these mechanisms.
Also note that: Also note that:
- Any documents including HTML documents that contain octet values - Any documents including HTML documents that contain octet values
outside the 7-bit range need a content-transfer-encoding applied outside the 7-bit range need a content-transfer-encoding applied
before transmission over certain transport protocols [MIME1, before transmission over certain transport protocols [MIME1,
chapter 5]. chapter 5].
- The MIME standard [MIME2] requires that e-mailed documents of - The MIME standard [MIME2] requires that e-mailed documents of
"Content-Type: Text/ MUST be in canonical form before a "Content-Type: Text/ MUST be in canonical form before a
Content-Transfer-Encoding is applied, i.e. that line breaks are Content-Transfer-Encoding is applied, i.e. that line breaks are
encoded as CRLFs, not as bare CRs or bare LFs or something else. 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 This is in contrast to [HTTP] where section 3.6.1 allows other
representations of line breaks. representations of line breaks.
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 based message integrity check becomes invalid, a way that a checksum based message integrity check becomes invalid,
then this integrity check header SHOULD be removed from the document. then this 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 character sets 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),
then the document SHOULD remain unconverted so that integrity check
sums are not invalidated.
A provider of HTML documents who wants his documents to be transferable
via both HTTP and SMTP without invalidating checksum integrity checks,
should always provide original documents in the canonical form with
CRLF for line breaks.
Some transport mechanisms may specify a default "charset" parameter if Some transport mechanisms may specify a default "charset" parameter if
none is supplied [HTTP, MIME1]. Because the default differs for none is supplied [HTTP, MIME1]. Because the default differs for
different mechanisms, when HTML is transferred through e-mail, the different mechanisms, when HTML is transferred through e-mail, the
charset parameter SHOULD be included, rather than relying on the charset parameter SHOULD be included, rather than relying on the
default. default.
12. Security Considerations 11. Security Considerations
Some Security Considerations include the potential to send someone an 11.1 Security considerations not related to caching
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 (like HTTP or FTP) 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
sources other than body parts included in the same multipart/related
structure 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.
URIs, especially File URIs, may in their name contain company-internal It is possible for a message sender to misrepresent the source of a
information, which may then inadvertently be revealed to recipients of multipart/related body part to a message recipient by labeling it with
documents containing such URIs. a Content-Location URI that references another resource. Therefore,
message recipients should only interpret Content-Location URIs as
labeling a body part for the resolution of references from body parts
in the same multipart/related message structure, and not as the source
of a resource, unless this can be verified by other means.
One way of implementing messages with URI linked body parts is to URIs, especially File URIs, if used without change in a message, may
handle the linked body parts in a combined mail and WWW proxy server. inadvertently reveal information that was not intended to be revealed
The mail client is only given the start body part, which it passes to a outside a particular security context. Message senders should take care
web browser. This web browser requests the linked parts from the proxy when constructing messages containing the new header fields, defined in
server. If this method is used, and if the combined server is used by this standard, that they are not revealing information outside of any
more than one user, then methods must be employed to ensure that body security contexts to which they belong.
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 WWW proxy servers may not
distinguish between cached objects from email and HTTP, which may be a
security risk.
In addition, by allowing people to mail aggregate objects, we are Some resource servers hide passwords and tickets (access tokens to
opening the door to other potential security problems that until now information which should not be reveled to others) and other sensitive
were only problems for WWW users. For example, some HTML documents now information in non-visible fields or URIs within a text/html resource.
either themselves contain executable content (JavaScript) or contain If such a text/html resource is forwarded in an email message, this
links to executable content (The "INSERT" specification, Java). It sensitive information may be inadvertently revealed to others.
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.
Some WWW applications hide passwords and tickets (access tokens to Since HTML documents can either directly contain executable content
information which may not be available to anyone) and other sensitive (i.e., JavaScript) or indirectly reference executable content (The
information in hidden fields in the web documents or in on-the-fly "INSERT" specification, Java). It is exceedingly dangerous for a
constructed URIs. If a person gets such a document, and forwards it via receiving User Agent to execute content received in a mail message
email, the person may inadvertently disclose sensitive information. without careful attention to restrictions on the capabilities of that
executable content. (Why??? I do not understand this! What
resdtrictions of what capabilities???/jp)
13. Differences as compared to the previous version of this proposed 11.2 Security considerations related to caching
There is a well-known problem with the caching of directly retrieved
web resources. A resource retrieved from a cache may differ from that
re-retrieved from its source. This problem, also manifests itself when
a copy of a resource is delivered in a multipart/related structure.
When processing (rendering) a text/html body part in an MHTML
multipart/related structure, all URIs in that text/html body part which
reference subsidiary resources within the same multipart/related
structure SHALL be satisfied by those resources and not by resources
from any another local or remote source.
Therefore, if a sender wishes a recipient to always retrieve an URI
referenced resource from its source, an URI labeled copy of that
resource MUST NOT be included in the same multipart/related structure.
In addition, since the source of a resource received in a
multipart/related structure can be misrepresented (see 11.1 above), if
a resource received in multipart/related structure is stored in a
cache, it MUST NOT be retrieved from that cache other than by a
reference contained in a body part of the same multipart/related
structure. Failure to honor this directive will allow a
multipart/related structure to be employed as a Trojan Horse. For
example, to inject bogus resources (i.e. a misrepresentation of a
competitor's Web site) into a recipient's generally accessible Web
cache.
12. Differences as compared to the previous version of this proposed
standard in RFC 2110 standard in RFC 2110
The specification has been changed to show that the formats described The specification has been changed to show that the formats described
do not only apply to multipart MIME in email, but also to multipart do not only apply to multipart MIME in email, but also to multipart
MIME transferred through other protocols such as HTTP or FTP. MIME transferred through other protocols such as HTTP or FTP.
In order to agree with [RELURL], Content-Base headers in multipart In order to agree with [RELURL], Content-Location headers in multipart
Content-Headings can now be used to resolve relative URIs in their Content-Headings can now be used as a base to resolve relative URIs in
component parts, but only if no base URI can be derived from the their component parts, but only if no base URI can be derived from the
component part itself. Base URIs in inner headings, both in Content- component part itself. Base URIs in Content-Location header fields in
Base and Content-Location headers, have precedence over base URIs in inner headings have precedence over base URIs in outer multipart
outer multipart headings. headings.
Specification has been added that a Content-Heading cannot contain more The Content-Base header, which was present in RFC 2110, has been
than one Content-Location header. removed. A conservative implementor may choose to accept this header in
input for compatibility with implementations of RFC 2110, but MUST
never send any Content-Base header, since this header is not any more a
part of this standard.
A section 4.4.1 has been added, specifying how to handle the case of A section 4.4.1 has been added, specifying how to handle the case of
sending a body part whose URI does not agree with the correct URI sending a body part whose URI does not agree with the correct URI
syntax. syntax.
The handling of relative and absolute URIs for matching between body The handling of relative and absolute URIs for matching between body
parts have been merged into a single description, by specifying that parts have been merged into a single description, by specifying that
relative URIs which cannot be resolved otherwise should be handled as relative URIs, which cannot be resolved otherwise, should be handled as
if they had been given imaginary URL "this_message:/". if they had been given the URL "this_message:/".
14. Copyright 13. Copyright
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society 1998. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the document itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet organizations, except as needed for the purpose of developing
skipping to change at line 1100 skipping to change at line 1172
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
15. Acknowledgments 14. Acknowledgments
Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin
J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul
Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg
Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt, Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt,
Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W. Peck, Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W. Peck,
Pete Resnick, Nick Shelness, Jon Smirl, Einar Stefferud, Jamie Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve Zilles
Zawinski, Steve Zilles and several other people have helped us with and several other people have helped us with preparing this document. I
preparing this document. I alone take responsibility for any errors alone take responsibility for any errors which may still be in the
which may still be in the document. document.
16. References 15. References
Ref. Author, title Ref. Author, title
--------- -------------------------------------------------------- --------- --------------------------------------------------------
|ABNF] D. Rocker, P. Overell: Augmented BNF for Syntax
Specifications: ABNF, RFC 2234, November 1997.
[CONDISP] R. Troost, S. Dorner: "Communicating Presentation [CONDISP] R. Troost, S. Dorner: "Communicating Presentation
Information in Internet Messages: The Information in Internet Messages: The
Content-Disposition Header", RFC 1806, June 1995. Content-Disposition Header", RFC 1806, June 1995.
[HOSTS] R. Braden (editor): "Requirements for Internet Hosts -- [HOSTS] R. Braden (editor): "Requirements for Internet Hosts --
Application and Support", STD-3, RFC 1123, October 1989. Application and Support", STD-3, RFC 1123, October 1989.
[HTML-I18N] F. Yergeau, G. Nicol, G. Adams, & M. Duerst: [HTML-I18N] F. Yergeau, G. Nicol, G. Adams, & M. Duerst:
"Internationalization of the Hypertext Markup Language". "Internationalization of the Hypertext Markup Language".
RFC 2070, January 1997. RFC 2070, January 1997.
[HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup Language [HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup Language
- 2.0", RFC 1866, November 1995. - 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] 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.
[IETF-TERMS] S. Bradner: Key words for use in RFCs to Indicate
Requirements Levels. RFC 2119, March 1997.
[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: Content-ID and Message-ID Uniform Resource
Access"Message/External-Body Content-ID and Message-ID Locators", draft-ietf-mhtml-cid-v2-00.txt, July 1997.
Uniform Resource Locators", draft-ietf-mhtml-cid-v2-
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, "Multipurpose Internet Mail [MIME-IMB] N. Freed & N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bedies". RFC 2045, November 1996. Bedies". RFC 2045, November 1996.
[MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail [MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail
skipping to change at line 1205 skipping to change at line 1286
Resource Locators (URL)", RFC 1738, December 1994. Resource Locators (URL)", RFC 1738, December 1994.
[URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME [URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME
External-Body Access-Type", RFC 2017, October 1996. External-Body Access-Type", RFC 2017, October 1996.
[VRML] Gavin Bell, Anthony Parisi, Mark Pesce: "Virtual Reality [VRML] Gavin Bell, Anthony Parisi, Mark Pesce: "Virtual Reality
Modeling Language (VRML) Version 1.0 Language Modeling Language (VRML) Version 1.0 Language
Specification." May 1995, Specification." May 1995,
http://www.vrml.org/Specifications/. http://www.vrml.org/Specifications/.
[IETF-TERMS] S. Bradner: Key words for use in RFCs to Indicate [XML] Extensible Markup Language, published by the World Wide
Requirements Levels. RFC 2119, March 1997. Web Consortium, URL http://www.w3.org/XML/
17. Author's Addresses 16. Author's Addresses
For contacting the editors, preferably write to Jacob Palme rather than For contacting the editors, preferably write to Jacob Palme.
Alex Hopmann.
Jacob Palme Phone: +46-8-16 16 67 Jacob Palme Phone: +46-8-16 16 67
Stockholm University and KTH Fax: +46-8-783 08 29 Stockholm University and KTH Fax: +46-8-783 08 29
Electrum 230 Email: jpalme@dsv.su.se Electrum 230 Email: jpalme@dsv.su.se
S-164 40 Kista, Sweden S-164 40 Kista, Sweden
Alex Hopmann Email: alexhop@microsoft.com Alex Hopmann Email: alexhop@microsoft.com
Microsoft Corporation Microsoft Corporation Phone: +1-425-703-8238
3590 North First Street One Microsoft Way
Suite 300 Redmond WA 98052
San Jose
CA 95134 Nick Shelness Email: Shelness@lotus.com
Lotus Development Corporation
55 Cambridge Parkway
Cambridge MA 02142-1295
Working group chairman: Working group chairman:
Einar Stefferud <stef@nma.com> Einar Stefferud Email: stef@nma.com
 End of changes. 128 change blocks. 
376 lines changed or deleted 458 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/